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

[Mateusz Guzik <mjguzik@gmail.com>]

On Wed, Jan 14, 2026 at 1:41 PM David Hildenbrand (Red Hat)
<david@kernel.org> wrote:
>
> 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.
> >

Of course.

I'm stating that with dedicated threads for zeroing, provided there is
some memory available along with cpu time, it can be paid while
nothing actively needs these pages.

> > 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).
>

Framing this as "increase application startup" and merely shifting the
overhead to shutdown seems like gaming the problem statement to me.
The real problem is total real time spent on it while pages are
needed.

Support for background zeroing can give you more usable pages provided
it has the cpu + ram to do it. If it does not, you are in the worst
case in the same spot as with zeroing on free.

Let's take a look at some examples.

Say there are no free huge pages and you kill a vm + start a new one.
On top of that all CPUs are pegged as is. In this case total time is
the same for "zero on free" as it is for background zeroing.

Say the system is freshly booted and you start up a vm. There are no
pre-zeroed pages available so it suffers at start time no matter what.
However, with some support for background zeroing, the machinery could
respond to demand and do it in parallel in some capacity, shortening
the real time needed.

Say a little bit of real time passes and you start another vm. With
merely zeroing on free there are still no pre-zeroed pages available
so it again suffers the overhead. With background zeroing some of the
that memory would be already sorted out, speeding up said startup.