Re: [PATCH] fork: zero vmap stack using clear_pages() instead of memset()

["David Hildenbrand (Arm)" <david@kernel.org>]

On 2/24/26 14:53, Linus Walleij wrote:
> On Tue, Feb 24, 2026 at 2:21 PM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
>> On 2/24/26 11:26, Linus Walleij wrote:
> 
>>> After the introduction of clear_pages() we exploit the
>>> fact that the process vm_area is allocated in contiguous
>>> pages to just clear them all in one swift operation.
>>
>> The pages are virtually contiguous (vmalloc IIUC), not necessarily
>> physically contiguous. For clear_pages() that should work.
> 
> Yeah that's what I meant with contiguous, sorry.
> 
>>>               /* Clear stale pointers from reused stack. */
>>> -             memset(stack, 0, THREAD_SIZE);
>>> +             clear_pages(vm_area->addr, vm_area->nr_pages);
>>
>> LGTM.
>>
>> Do we have any idea about performance impact etc?
> 
> I have a pending patch for implementing clear_pages() for arm64,
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=b4/aarch64-clear-pages
> which is in a performance test loop, once I get baseline data from that
> I can test something fork-intensive (hackbench, I guess) with this patch on top.
> 
> So making that patch made me remember this one code site...

I'll note that clear_pages() documents: "When running under preemptible
models this is not a problem. Under cooperatively scheduled models,
however, the caller is expected to limit @npages to no more than
PROCESS_PAGES_NON_PREEMPT_BATCH."

We discussed during review that we should probably move that batching
logic into clear_pages() at some point.

PROCESS_PAGES_NON_PREEMPT_BATCH defaults to 1. I'd assume that handling
3 pages here doesn't make a difference, just pointing it out.

CCing Ankur.

> 
> If someone has a good fork performance test running on x86
> and can give this a spin, it'd be great!

That would be nice :)


-- 
Cheers,

David