On Wed, Feb 21, 2018 at 7:23 AM, Konstantin Khlebnikov <khlebni...@yandex-team.ru> wrote: > > > On 21.02.2018 03:16, Andrew Morton wrote: >> >> On Tue, 23 Jan 2018 16:57:21 +0300 Konstantin Khlebnikov >> <khlebni...@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.
Or someone could *fix* KASAN to work with stacks in the vmalloc area.
