Messages in this thread | | | Date | Tue, 20 Feb 2018 16:16:34 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH 3/4] kernel/fork: switch vmapped stack callation to __vmalloc_area() |
| |
On Tue, 23 Jan 2018 16:57:21 +0300 Konstantin Khlebnikov <khlebnikov@yandex-team.ru> wrote:
> # stress-ng --clone 100 -t 10s --metrics-brief > at 32-core machine shows boost 35000 -> 36000 bogo ops > > Patch 4/4 is a kind of RFC. > Actually per-cpu cache of preallocated stacks works faster than buddy allocator thus > performance boots for it happens only at completely insane rate of clones. >
I'm not really sure what to make of this patchset. Is it useful in any known real-world use cases?
> + This option neutralize stack overflow protection but allows to > + achieve best performance for syscalls fork() and clone().
That sounds problematic, but perhaps acceptable if the fallback only happens rarely.
Can this code be folded into CONFIG_VMAP_STACk in some cleaner fashion? We now have options for non-vmapped stacks, vmapped stacks and a mix of both.
And what about this comment in arch/Kconfig:VMAP_STACK:
This is presently incompatible with KASAN because KASAN expects the stack to map directly to the KASAN shadow map using a formula that is incorrect if the stack is in vmalloc space.
So VMAP_STACK_AS_FALLBACK will intermittently break KASAN?
| |