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

[Brendan Jackman <jackmanb@google.com>]

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?