| 1 |
> > i remember only the kernel compiles on P3, for SEGMEXEC the slowdown |
| 2 |
> > was around 1-2%, for PAGEEXEC on 2.2/2.4 it was around 30-40% and |
| 3 |
> > on 2.6 it was 2-3%. |
| 4 |
> |
| 5 |
> why is there such a difference between using PAGEEXEC on 2.4 and using it on |
| 6 |
> 2.6? |
| 7 |
|
| 8 |
because 2.6 is an experimental branch so i did my own experiment ;-). |
| 9 |
more seriously, i added a tweak to PAGEEXEC that makes the code |
| 10 |
segment limit variable and everything above that limit can then be |
| 11 |
mapped with normal user mode page table entries -> less extra page |
| 12 |
faults, less impact. now this works as long as 'most' non-exec |
| 13 |
mappings can be pushed above the code segment limit, to that effect |
| 14 |
i made the mmap allocator push executable mappings in the lower part |
| 15 |
of the address space, rest goes above as usual (2.6 allocates from |
| 16 |
top to down itself). as you can see from the performance numbers, |
| 17 |
this heuristics works quite well on a kernel compilation, on other |
| 18 |
workloads 'it depends', mostly on how shared libs are mapped (as |
| 19 |
they have code hence mapping them 'too high' will necessarily push |
| 20 |
the code segment limit upwards and makes all non-exec mappings below |
| 21 |
use the supervisor mode PTEs -> more impact). |
| 22 |
|
| 23 |
-- |
| 24 |
gentoo-hardened@g.o mailing list |
Archives