Re: [PATCH v2 0/8] Introduce a huge-page pre-zeroing mechanism

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

On 1/14/26 13:33, David Hildenbrand (Red Hat) wrote:
> On 1/14/26 13:11, Mateusz Guzik wrote:
>> On Wed, Jan 14, 2026 at 12:55 PM David Hildenbrand (Red Hat)
>> <david@kernel.org> wrote:
>>> You said "I wonder if implementing hugepage pre-zeroing directly within
>>> the kernel would be a simpler and more direct way to accelerate VM
>>> creation".
>>>
>>> And I agree. But to make that fly (no user space polling interface), I
>>> was wondering whether we could do it like "init_on_free" and let whoever
>>> frees a hugetlb folio just reinitialize it with 0.
>>>
>>> No kernel thread, no user space thread involved.
>>>
>>
>> i don't see how this is supposed to address the stated problem of
>> zeroing being incredibly expensive.
> 
> The price of zeroing has to be paid somewhere.
> 
> Currently it's done at allocation time, we could move it to freeing time.
> 
> That would make application startup faster and application shutdown slower.
> 
> And we're aware that application shutdown can be expensive, which is why
> e.g., QEMU implements an async shutdown operation, where the MM gets
> torn down from another process.

Also, just to mention it, assuming a VM is backed by a hugetlb file, the 
user space thread destroying that file (or parts of it by punshing holes 
and freeing hugetlb folios) would be paying that price.

That could be done whenever there is a CPU to spare to perform some freeing.

But again, I think the main motivation here is "increase application 
startup", not optimize that the zeroing happens at specific points in 
time during system operation (e.g., when idle etc).

-- 
Cheers

David