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

[Brendan Jackman <jackmanb@google.com>]

On Fri Mar 20, 2026 at 9:48 AM UTC, 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.  

Oh, but also couldn't we get those 3 back by expanding struct
radix_tree_root as I suggested a few messages back:

-#define radix_tree_root                xarray
+struct radix_tree_root {
+        struct xarray xarray;
+        gfp_t gfp;
+};

That seems to make sense as a way to avoid the xa_flags overload even if
gfp_t doesn't grow.

(_If_ we can tolerate radix_tree_root expansion, which I have no idea
about. Otherwise, yeah seems like finishing the radix-tree migration is
a good path to more GFP flags).