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

[David Hildenbrand (Arm)]

On 4/23/26 06:31, Gregory Price wrote:
> On Wed, Apr 22, 2026 at 05:20:27PM -0400, Michael S. Tsirkin wrote:
>> On Wed, Apr 22, 2026 at 03:47:07PM -0400, Gregory Price wrote:
>>>
>>> __alloc_user_pages(..., gfp_t gfp, user_addr)
>>
>> With a wrapper approach, looks like we'd need something like
>> __GFP_SKIP_ZERO so post_alloc_hook doesn't zero sequentially, then the
>> wrapper re-zeros with folio_zero_user().  But then the wrapper needs to
>> know whether the page was pre-zeroed (PG_zeroed), which is cleared by
>> post_alloc_hook before return.  So the information doesn't survive to
>> the wrapper.
>>
> 
> I was thinking more that internally you already have that information
> you need to know to skip the zeroing - and so the wrapper can just pass
> __GFP_ZERO and post_alloc_hook() would do the right thing regardless
> 
> Then on the way out, the new wrapper would take care of cacheline piece.
> 
> However, i explored this a bit - and while it saves some churn on the
> interface, it adds two paths into the buddy - and that increase in
> surface might not be worth it.
> 
> So I see the tradeoff here.  The churn is probably worth it.

In v2 I commented [1]

"
For example, instead of changing all callers of post_alloc_hook() to
pass USER_ADDR_NONE, can we make post_alloc_hook() a simple wrapper
around a variant that consumes an address.

So isn't there a way we can just keep the changes mostly to mm/page_alloc.c?
"

That should avoid most of the churn outside of page_alloc, no?

[1] https://lore.kernel.org/r/4bdc66f2-1469-4b91-9935-74c3d3ca0ed9@xxxxxxxxxx

-- 
Cheers,

David