Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long

[Vlastimil Babka (SUSE)]

On 3/20/26 10:48, Brendan Jackman wrote:
> On Thu Mar 19, 2026 at 9:39 PM UTC, Matthew Wilcox wrote:
>> On Thu, Mar 19, 2026 at 06:40:59PM +0000, Brendan Jackman wrote:
>>> I will paste the diff at the bottom. I _think_ all the problematic
>>> expansions are downstream of struct xarray, but it's quite likely my
>>> sense for problematic struct expansions is weak.
>>
>> Urgh, no, it's not all xarray.  There's one in address_space which we're
>> trying to shrink, not grow.  
> 
> Oh sorry I just assumed that one was xa_flags.
> 
>> There's one in struct sock too.
> 
> Huh, I suspect I am embarassing myself with this question, but why are
> we sensitive to the size of struct sock? It's currently 784 bytes in my
> build. Are the adjacent fields very hot, and we need to look up the GFP
> flags from hot paths?
> 
>> I don't think this idea is worth it.  There are other projects of greater
>> or lesser churniess which will give us some flags back.  For example,
>> we could finish the GFP_NOFS and GFP_NOIO removal.  We could finish the
>> radix_tree -> XArray removal and get back three bits.  That's five bits
>> without even starting new projects, just finishing old ones.
> 
> Anyway, this also makes sense. But, Vlastimil, I guess you had an
> ulterior motive for this suggestion?

Partially. After seeing various issues with kmalloc_nolock() relying on lack
of __GFP_KSWAPD_RECLAIM to indicate the nolock, it would be great to just
add another gfp flag for it, but with only few left, I didn't dare.

But I'll admit it wasn't well thought idea out wrt consequences. Sorry that
nobody shot it down before you actually tried to implement it.