On Wed, Feb 21, 2018 at 7:23 AM, Konstantin Khlebnikov <khlebnikov@xxxxxxxxxxxxxx> wrote: > > > On 21.02.2018 03:16, Andrew Morton wrote: >> >> On Tue, 23 Jan 2018 16:57:21 +0300 Konstantin Khlebnikov >> <khlebnikov@xxxxxxxxxxxxxx> 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
