Re: [RFC PATCH] fork: Free per-cpu cached vmalloc'ed thread stacks with

2020-09-13 Thread Andrew Morton
On Sat, 5 Sep 2020 00:12:29 + "Isaac J. Manjarres" wrote: > The per-cpu cached vmalloc'ed stacks are currently freed in the > CPU hotplug teardown path by the free_vm_stack_cache() callback, > which invokes vfree(), which may result in purging the list of > lazily freed vmap areas. > > Purg

Re: [RFC PATCH] fork: Free per-cpu cached vmalloc'ed thread stacks with

2020-09-07 Thread Uladzislau Rezki
On Mon, Sep 07, 2020 at 10:45:38AM +0200, Christian Brauner wrote: > On Sat, Sep 05, 2020 at 12:12:29AM +, Isaac J. Manjarres wrote: > > The per-cpu cached vmalloc'ed stacks are currently freed in the > > CPU hotplug teardown path by the free_vm_stack_cache() callback, > > which invokes vfree()

Re: [RFC PATCH] fork: Free per-cpu cached vmalloc'ed thread stacks with

2020-09-07 Thread Christian Brauner
On Sat, Sep 05, 2020 at 12:12:29AM +, Isaac J. Manjarres wrote: > The per-cpu cached vmalloc'ed stacks are currently freed in the > CPU hotplug teardown path by the free_vm_stack_cache() callback, > which invokes vfree(), which may result in purging the list of > lazily freed vmap areas. > > P

[RFC PATCH] fork: Free per-cpu cached vmalloc'ed thread stacks with

2020-09-04 Thread Isaac J. Manjarres
The per-cpu cached vmalloc'ed stacks are currently freed in the CPU hotplug teardown path by the free_vm_stack_cache() callback, which invokes vfree(), which may result in purging the list of lazily freed vmap areas. Purging all of the lazily freed vmap areas can take a long time when the list of