Messages in this thread | | | Date | Sat, 30 May 2009 19:50:03 +0200 | From | Ingo Molnar <> | Subject | Re: [patch 0/5] Support for sanitization flag in low-level page allocator |
| |
* pageexec@freemail.hu <pageexec@freemail.hu> wrote:
> On 28 May 2009 at 11:08, Ingo Molnar wrote: > > > > > * Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > > > > > > > As for being swapped out - I do not believe that kernel stacks can > > > > > ever be swapped out in Linux. > > > > > > > > yes, i referred to that as an undesirable option - because it slows > > > > down pthread_create() quite substantially. > > > > > > > > This needs before/after pthread_create() benchmark results. > > > > > > kernel stacks can end up places you don't expect on hypervisor > > > based systems. > > > > > > In most respects the benchmarks are pretty irrelevant - wiping > > > stuff has a performance cost, but its the sort of thing you only > > > want to do when you have a security requirement that needs it. At > > > that point the performance is secondary. > > > > Bechmarks, of course, are not irrelevant _at all_. > > > > So i'm asking for this "clear kernel stacks on freeing" aspect to be > > benchmarked thoroughly, as i expect it to have a negative impact - > > otherwise i'm NAK-ing this. Please Cc: me to measurements results. > > last year while developing/debugging something else i also ran some kernel > compilation tests and managed to dig out this one for you ('all' refers to > all of PaX): > > ------------------------------------------------------------------------------------------ > make -j4 2.6.24-rc7-i386-pax compiling 2.6.24-rc7-i386-pax (all with SANITIZE, no PARAVIRT) > 565.63user 68.52system 5:25.52elapsed 194%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (1major+12486066minor)pagefaults 0swaps > > 565.10user 68.28system 5:24.72elapsed 195%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (0major+12485742minor)pagefaults 0swaps > ------------------------------------------------------------------------------------------ > make -j4 2.6.24-rc5-i386-pax compiling 2.6.24-rc5-i386-pax (all but SANITIZE, no PARAVIRT) > 559.74user 50.29system 5:12.79elapsed 195%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (0major+12397482minor)pagefaults 0swaps > > 561.41user 51.91system 5:14.55elapsed 194%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (0major+12396877minor)pagefaults 0swaps > ------------------------------------------------------------------------------------------ > > for the kernel times the overhead is about 68s vs. 51s, or 40% in > this particular case. while i don't know where this workload (the > kernel part) falls in the spectrum of real life workloads, it > definitely shows that if you're kernel bound, you should think > twice before using this in production (and there's the real-time > latency issue too).
Yes, clearing memory causes quite brutal overhead - as expected.
If only kernel stacks are cleared before reuse that will be less overhead - but still it has to be benchmarked (and the overhead has to be justified).
Ingo
| |