Re: [PATCH RFC v3 01/19] mm: thread user_addr through page allocator for cache-friendly zeroing

[Gregory Price <gourry@gourry.net>]

On Thu, Apr 23, 2026 at 07:57:01AM -0400, Michael S. Tsirkin wrote:
> On Thu, Apr 23, 2026 at 11:46:56AM +0200, David Hildenbrand (Arm) wrote:
> > On 4/23/26 06:31, Gregory Price wrote:
> 
> Changes we have to add: 8 changes
> Rename 4 existing APIs adding _user: __alloc_pages,
> __folio_alloc, folio_alloc_mpol, __alloc_frozen_pages + add
> 4 wrapper macros/inlines in gfp.h that forward to the _user variants with
> USER_ADDR_NONE. Roughly 6-8 lines of boilerplate per API.
>

This is essentially what i was proposing.

The result would be more external surface to the buddy (at least 2 maybe
more functions, plus all the _noprof stuff and a bunch of other things).

And then all the callers have to be updated anywhere, and not make it
any harder to mess up.  You either have

    old_interface(..., user_addr);
    /* Churn everything using the old interface */

or

    __internal(..., user_addr) { }

    old_interface(...) {
       __internal(..., NO_USER_ADDR);
    }

    new_interface(..., user_addr) {
       __internal(..., user_addr);
    }

    /* 
     * Update some callsites to use new_interface()
     * mostly a bunch of _mpol() functions but some others
     */

but someone could still just as easily do

    old_interface();
    /* don't fall folio_zero_user() - Bug! */

So it's not like this makes things any harder to mess up.

There is no elegant fix here if we want to do this all inside the buddy.

If the performance increase weren't so blatantly dramatic we could also
consider just not doing this at all.

There's maybe an alternative here in considering a change to the way the
buddy manages zeroed pages - but there's no guarantees we find a pattern
there either.

~Gregory