On Tue, Apr 21, 2026 at 06:01:10PM -0400, Michael S. Tsirkin wrote:
> Thread a user virtual address from vma_alloc_folio() down through
> the page allocator to post_alloc_hook(). This is plumbing preparation
> for a subsequent patch that will use user_addr to call folio_zero_user()
> for cache-friendly zeroing of user pages.
>
> The user_addr is stored in struct alloc_context and flows through:
> vma_alloc_folio -> folio_alloc_mpol -> __alloc_pages_mpol ->
> __alloc_frozen_pages -> get_page_from_freelist -> prep_new_page ->
> post_alloc_hook
>
> Public APIs (__alloc_pages, __folio_alloc, folio_alloc_mpol) gain a
> user_addr parameter directly. Callers that do not need user_addr
> pass USER_ADDR_NONE ((unsigned long)-1), since
> address 0 is a valid user mapping.
>
Question: rather than churning the entirety of the existing interfaces,
is there a possibility of adding an explicit interface for this
interaction that amounts to:
__alloc_user_pages(..., gfp_t gfp, user_addr)
{
BUG_ON(!(gfp & __GFP_ZERO));
/* post_alloc_hook implements the already-zeroed skip */
page = alloc_page(..., gfp, ...); /* existing interface */
/* Do the cacheline stuff here instead of in the core */
cacheline_nonsense(page, user_addr);
return page; /* user doesn't need to do explicit zeroing */
}
Then rather than leaking information out of the buddy, we just need to
get the zeroed information *into* the buddy.
the users that want zeroing but need the explicit user_addr step just
defer the zeroing to outside post_alloc_hook().
That's just my immediate gut reaction to all this churn on the existing
interfaces.
Existing users can continue using the buddy as-is, and enlightened users
can optimize for this specific kind of __GFP_ZERO interaction.
~Gregory
