Messages in this thread | | | Subject | Re: [PATCH 3/4] kernel/fork: switch vmapped stack callation to __vmalloc_area() | From | Konstantin Khlebnikov <> | Date | Wed, 21 Feb 2018 10:23:12 +0300 |
| |
On 21.02.2018 03:16, Andrew Morton wrote: > 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?
Not yet. Feel free to ignore last patch.
> >> + 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? >
All of this (including CONFIG_VMAP_STACK) could be turned into boot option. I think this would be a best solution.
| |