drivers/gpu/drm/drm_managed.c | 4 ++-- drivers/net/wireless/intel/iwlegacy/3945-mac.c | 4 ++-- include/linux/types.h | 2 +- lib/test_lockup.c | 2 +- mm/kfence/kfence_test.c | 2 +- mm/oom_kill.c | 2 +- mm/page_alloc.c | 5 ++++- mm/page_owner.c | 4 ++-- mm/slab_common.c | 2 +- mm/slub.c | 2 +- mm/vmalloc.c | 2 +- net/rds/tcp_recv.c | 2 +- 12 files changed, 18 insertions(+), 15 deletions(-)
As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is
probably not needed for 32-bit. This offers a way out of the GFP flag
scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit
machines, while leaving it 32-bit on 32-bit machines.
For mm-internal code that prints raw GFP flags as hex, this just updates
the format specifier to %lx. Presumably developers have a reason for
wanting to see the whole flags word as a number in the log. For printks
outside of mm/, I assume they are only using %x because the authors
didn't know about %pGg, so they are converted to the latter as prep
patches.
Stuff I've done to try and find issues with this:
- Built x86 allmodconfig and arm64 defconfig. Hopefully the 0-day bot
will alert me to the important builds I'm missing (I briefly tried to
build s390 and sparc64 but ran into tooling issues and gave up).
- Ran some selftests on a x86 VM.
- Poked around at stuff that refers to ___GFP_LAST_BIT to see if
anything looks wrong.
- Ran this Coccinelle script to look for explicit casts to plain int:
---
virtual report
@r@
gfp_t x;
position p;
@@
(
(unsigned int)x@p
|
(int)x@p
)
@script:python depends on report@
p << r.p;
@@
msg = "WARNING: Explicit integer cast of gfp_t"
coccilib.report.print_report(p[0], msg)
---
Obviously this series doesn't "do anything" so maybe it doesn't make
sense to merge it unless it goes in alongside __GFP_UNMAPPED, but it
does seem to make sense to review it independently so I'm posting it as
a separate series.
[0] https://lore.kernel.org/all/6206d021-e6c2-4899-b426-cacd71ebd5ef@kernel.org/
To: Andrew Morton <akpm@linux-foundation.org>
To: Michal Hocko <mhocko@suse.com>
To: David Rientjes <rientjes@google.com>
To: Shakeel Butt <shakeel.butt@linux.dev>
To: Vlastimil Babka <vbabka@kernel.org>
To: Suren Baghdasaryan <surenb@google.com>
To: Brendan Jackman <jackmanb@google.com>
To: Johannes Weiner <hannes@cmpxchg.org>
To: Zi Yan <ziy@nvidia.com>
To: Harry Yoo <harry.yoo@oracle.com>
To: Hao Li <hao.li@linux.dev>
To: Christoph Lameter <cl@gentwo.org>
To: Roman Gushchin <roman.gushchin@linux.dev>
To: Uladzislau Rezki <urezki@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org
Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
Brendan Jackman (5):
drm/managed: Use special gfp_t format specifier
iwlegacy: 3945-mac: Use special gfp_t format specifier
mm/kfence: Use special gfp_t format specifier
net/rds: Use special gfp_t format specifier
mm: Change gfp_t to unsigned long
drivers/gpu/drm/drm_managed.c | 4 ++--
drivers/net/wireless/intel/iwlegacy/3945-mac.c | 4 ++--
include/linux/types.h | 2 +-
lib/test_lockup.c | 2 +-
mm/kfence/kfence_test.c | 2 +-
mm/oom_kill.c | 2 +-
mm/page_alloc.c | 5 ++++-
mm/page_owner.c | 4 ++--
mm/slab_common.c | 2 +-
mm/slub.c | 2 +-
mm/vmalloc.c | 2 +-
net/rds/tcp_recv.c | 2 +-
12 files changed, 18 insertions(+), 15 deletions(-)
---
base-commit: 8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb
change-id: 20260319-gfp64-7a970a80ba4e
Best regards,
--
Brendan Jackman <jackmanb@google.com>
Human summary of Sashiko (AI) review [0]
[PATCH 2/5] iwlegacy: 3945-mac: Use special gfp_t format specifier
Just identifying pre-existing (and low-stakes) issues in the code. I
can add a patch to fix them up.
Andrew, I think it probably makes sense to merge these cleanup patches
regardless of the gfp_t change, as Zi said. Would you take them
through mm or would they need to go via the more specific branches?
[PATCH 5/5] mm: Change gfp_t to unsigned long
- 1 << __GFP_BITS_SHIFT needs to be updated to use 1UL.
- Need to update userspace tools like perf.
- Says I can't use unsigned long in module_param_unsafe(), which I
think is true. I did that to address a build failure, maybe I never
actually repeated the build?
Other patches got a green tick.
[0] https://sashiko.dev/#/patchset/20260319-gfp64-v1-0-2c73b8d42b7f%40google.com
On Fri, 20 Mar 2026 09:37:52 +0000 Brendan Jackman <jackmanb@google.com> wrote: > Human summary of Sashiko (AI) review [0] > > [PATCH 2/5] iwlegacy: 3945-mac: Use special gfp_t format specifier > > Just identifying pre-existing (and low-stakes) issues in the code. I > can add a patch to fix them up. > > Andrew, I think it probably makes sense to merge these cleanup patches > regardless of the gfp_t change, as Zi said. Would you take them > through mm or would they need to go via the more specific branches? In an ideal world the subsystem trees would take such changes. In the real world it's more reliable for me to take them all, make sure the relevant maintainers are cc'ed. If they ack the patch then great. If they merge the patch then I'll drop the mm.git duplicate. If they say nothing and it has decent linux-next exposure then ho hum, in it goes.
On 19 Mar 2026, at 12:03, Brendan Jackman wrote: > As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is > probably not needed for 32-bit. This offers a way out of the GFP flag > scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit > machines, while leaving it 32-bit on 32-bit machines. > > For mm-internal code that prints raw GFP flags as hex, this just updates > the format specifier to %lx. Presumably developers have a reason for > wanting to see the whole flags word as a number in the log. For printks > outside of mm/, I assume they are only using %x because the authors > didn't know about %pGg, so they are converted to the latter as prep > patches. I think these %lx -> %pGg patches can be merged. They are nice cleanups. Thank you for doing that. Feel free to add Reviewed-by: Zi Yan <ziy@nvidia.com> to the first 4 patches. (I did not put the tag in a newline, so that b4 will not mistakenly take it for the whole series) For patch 5, I will wait until you address the feedback from Vlastimil and Matthew. > > Stuff I've done to try and find issues with this: > > - Built x86 allmodconfig and arm64 defconfig. Hopefully the 0-day bot > will alert me to the important builds I'm missing (I briefly tried to > build s390 and sparc64 but ran into tooling issues and gave up). > > - Ran some selftests on a x86 VM. > > - Poked around at stuff that refers to ___GFP_LAST_BIT to see if > anything looks wrong. > > - Ran this Coccinelle script to look for explicit casts to plain int: > > --- > virtual report > > @r@ > gfp_t x; > position p; > @@ > > ( > (unsigned int)x@p > | > (int)x@p > ) > > @script:python depends on report@ > p << r.p; > @@ > msg = "WARNING: Explicit integer cast of gfp_t" > coccilib.report.print_report(p[0], msg) > --- > > Obviously this series doesn't "do anything" so maybe it doesn't make > sense to merge it unless it goes in alongside __GFP_UNMAPPED, but it > does seem to make sense to review it independently so I'm posting it as > a separate series. > > [0] https://lore.kernel.org/all/6206d021-e6c2-4899-b426-cacd71ebd5ef@kernel.org/ > > To: Andrew Morton <akpm@linux-foundation.org> > To: Michal Hocko <mhocko@suse.com> > To: David Rientjes <rientjes@google.com> > To: Shakeel Butt <shakeel.butt@linux.dev> > To: Vlastimil Babka <vbabka@kernel.org> > To: Suren Baghdasaryan <surenb@google.com> > To: Brendan Jackman <jackmanb@google.com> > To: Johannes Weiner <hannes@cmpxchg.org> > To: Zi Yan <ziy@nvidia.com> > To: Harry Yoo <harry.yoo@oracle.com> > To: Hao Li <hao.li@linux.dev> > To: Christoph Lameter <cl@gentwo.org> > To: Roman Gushchin <roman.gushchin@linux.dev> > To: Uladzislau Rezki <urezki@gmail.com> > Cc: linux-kernel@vger.kernel.org > Cc: linux-mm@kvack.org > > Signed-off-by: Brendan Jackman <jackmanb@google.com> > > --- > Brendan Jackman (5): > drm/managed: Use special gfp_t format specifier > iwlegacy: 3945-mac: Use special gfp_t format specifier > mm/kfence: Use special gfp_t format specifier > net/rds: Use special gfp_t format specifier > mm: Change gfp_t to unsigned long > > drivers/gpu/drm/drm_managed.c | 4 ++-- > drivers/net/wireless/intel/iwlegacy/3945-mac.c | 4 ++-- > include/linux/types.h | 2 +- > lib/test_lockup.c | 2 +- > mm/kfence/kfence_test.c | 2 +- > mm/oom_kill.c | 2 +- > mm/page_alloc.c | 5 ++++- > mm/page_owner.c | 4 ++-- > mm/slab_common.c | 2 +- > mm/slub.c | 2 +- > mm/vmalloc.c | 2 +- > net/rds/tcp_recv.c | 2 +- > 12 files changed, 18 insertions(+), 15 deletions(-) > --- > base-commit: 8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb > change-id: 20260319-gfp64-7a970a80ba4e > > Best regards, > -- > Brendan Jackman <jackmanb@google.com> Best Regards, Yan, Zi
On 3/19/26 17:03, Brendan Jackman wrote: > As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is > probably not needed for 32-bit. This offers a way out of the GFP flag > scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit > machines, while leaving it 32-bit on 32-bit machines. Thanks for tackling this! But now I'm wondering, if we decide to change it, would it be worth trying to add some type safety too? To help with cases like the recent kmalloc_objs() footgun discussed in this comment thread https://lwn.net/Articles/1063356/ > For mm-internal code that prints raw GFP flags as hex, this just updates > the format specifier to %lx. Presumably developers have a reason for > wanting to see the whole flags word as a number in the log. For printks > outside of mm/, I assume they are only using %x because the authors > didn't know about %pGg, so they are converted to the latter as prep > patches. > > Stuff I've done to try and find issues with this: > > - Built x86 allmodconfig and arm64 defconfig. Hopefully the 0-day bot > will alert me to the important builds I'm missing (I briefly tried to > build s390 and sparc64 but ran into tooling issues and gave up). > > - Ran some selftests on a x86 VM. > > - Poked around at stuff that refers to ___GFP_LAST_BIT to see if > anything looks wrong. > > - Ran this Coccinelle script to look for explicit casts to plain int: > > --- > virtual report > > @r@ > gfp_t x; > position p; > @@ > > ( > (unsigned int)x@p > | > (int)x@p > ) > > @script:python depends on report@ > p << r.p; > @@ > msg = "WARNING: Explicit integer cast of gfp_t" > coccilib.report.print_report(p[0], msg) > --- > > Obviously this series doesn't "do anything" so maybe it doesn't make > sense to merge it unless it goes in alongside __GFP_UNMAPPED, but it > does seem to make sense to review it independently so I'm posting it as > a separate series. > > [0] https://lore.kernel.org/all/6206d021-e6c2-4899-b426-cacd71ebd5ef@kernel.org/ > > To: Andrew Morton <akpm@linux-foundation.org> > To: Michal Hocko <mhocko@suse.com> > To: David Rientjes <rientjes@google.com> > To: Shakeel Butt <shakeel.butt@linux.dev> > To: Vlastimil Babka <vbabka@kernel.org> > To: Suren Baghdasaryan <surenb@google.com> > To: Brendan Jackman <jackmanb@google.com> > To: Johannes Weiner <hannes@cmpxchg.org> > To: Zi Yan <ziy@nvidia.com> > To: Harry Yoo <harry.yoo@oracle.com> > To: Hao Li <hao.li@linux.dev> > To: Christoph Lameter <cl@gentwo.org> > To: Roman Gushchin <roman.gushchin@linux.dev> > To: Uladzislau Rezki <urezki@gmail.com> > Cc: linux-kernel@vger.kernel.org > Cc: linux-mm@kvack.org > > Signed-off-by: Brendan Jackman <jackmanb@google.com> > > --- > Brendan Jackman (5): > drm/managed: Use special gfp_t format specifier > iwlegacy: 3945-mac: Use special gfp_t format specifier > mm/kfence: Use special gfp_t format specifier > net/rds: Use special gfp_t format specifier > mm: Change gfp_t to unsigned long > > drivers/gpu/drm/drm_managed.c | 4 ++-- > drivers/net/wireless/intel/iwlegacy/3945-mac.c | 4 ++-- > include/linux/types.h | 2 +- > lib/test_lockup.c | 2 +- > mm/kfence/kfence_test.c | 2 +- > mm/oom_kill.c | 2 +- > mm/page_alloc.c | 5 ++++- > mm/page_owner.c | 4 ++-- > mm/slab_common.c | 2 +- > mm/slub.c | 2 +- > mm/vmalloc.c | 2 +- > net/rds/tcp_recv.c | 2 +- > 12 files changed, 18 insertions(+), 15 deletions(-) > --- > base-commit: 8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb > change-id: 20260319-gfp64-7a970a80ba4e > > Best regards,
On Thu, 19 Mar 2026 at 18:03, Vlastimil Babka (SUSE) <vbabka@kernel.org> wrote: > > On 3/19/26 17:03, Brendan Jackman wrote: > > As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is > > probably not needed for 32-bit. This offers a way out of the GFP flag > > scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit > > machines, while leaving it 32-bit on 32-bit machines. > > Thanks for tackling this! But now I'm wondering, if we decide to change it, > would it be worth trying to add some type safety too? To help with cases > like the recent kmalloc_objs() footgun discussed in this comment thread > https://lwn.net/Articles/1063356/ Do you mean something similar to pgprot_t? I did that in [0] but I'm rather sheepish about it, I only went for it because I think it's especially needed for the specific "type" due to the migration path creating a high type-unsafety risk. And that was totally local to a few files in mm/. Are there common issues with gfp_t in particular besides the kmalloc_objs() thing? If so then maybe it could make sense. It's not a problem I've ever run into myself though. [0] https://lore.kernel.org/all/20260225-page_alloc-unmapped-v1-8-e8808a03cd66@google.com/
On 3/19/26 18:38, Brendan Jackman wrote: > On Thu, 19 Mar 2026 at 18:03, Vlastimil Babka (SUSE) <vbabka@kernel.org> wrote: >> >> On 3/19/26 17:03, Brendan Jackman wrote: >> > As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is >> > probably not needed for 32-bit. This offers a way out of the GFP flag >> > scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit >> > machines, while leaving it 32-bit on 32-bit machines. >> >> Thanks for tackling this! But now I'm wondering, if we decide to change it, >> would it be worth trying to add some type safety too? To help with cases >> like the recent kmalloc_objs() footgun discussed in this comment thread >> https://lwn.net/Articles/1063356/ > > Do you mean something similar to pgprot_t? Yeah, at least I don't know a better way. > I did that in [0] but I'm rather sheepish about it, I only went for it Right. > because I think it's especially needed for the specific "type" due to > the migration path creating a high type-unsafety risk. And that was > totally local to a few files in mm/. > > Are there common issues with gfp_t in particular besides the > kmalloc_objs() thing? If so then maybe it could make sense. It's not a > problem I've ever run into myself though. I think it's a hazard in any case where there are multiple arguments to a function where one is gfp flags and other some integer, and somebody gets the order wrong. But I just verified that at least in the kmalloc_objs() mistake, sparse will flag it, thanks to the __bitwise annotation. Would be better if compiler did, but it makes the case for changing gfp_t smaller if it was too disruptive (it likely would be). > [0] https://lore.kernel.org/all/20260225-page_alloc-unmapped-v1-8-e8808a03cd66@google.com/
On Thu Mar 19, 2026 at 7:58 PM UTC, Vlastimil Babka (SUSE) wrote: > On 3/19/26 18:38, Brendan Jackman wrote: >> On Thu, 19 Mar 2026 at 18:03, Vlastimil Babka (SUSE) <vbabka@kernel.org> wrote: >>> >>> On 3/19/26 17:03, Brendan Jackman wrote: >>> > As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is >>> > probably not needed for 32-bit. This offers a way out of the GFP flag >>> > scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit >>> > machines, while leaving it 32-bit on 32-bit machines. >>> >>> Thanks for tackling this! But now I'm wondering, if we decide to change it, >>> would it be worth trying to add some type safety too? To help with cases >>> like the recent kmalloc_objs() footgun discussed in this comment thread >>> https://lwn.net/Articles/1063356/ >> >> Do you mean something similar to pgprot_t? > > Yeah, at least I don't know a better way. > >> I did that in [0] but I'm rather sheepish about it, I only went for it > > Right. > >> because I think it's especially needed for the specific "type" due to >> the migration path creating a high type-unsafety risk. And that was >> totally local to a few files in mm/. >> >> Are there common issues with gfp_t in particular besides the >> kmalloc_objs() thing? If so then maybe it could make sense. It's not a >> problem I've ever run into myself though. > > I think it's a hazard in any case where there are multiple arguments to a > function where one is gfp flags and other some integer, and somebody gets > the order wrong. I think this is a C problem rather than a gfp_t problem though. Better to try and tackle it with treewide efforts like Sparse and Rust IMO. (Maybe gfp_t is the most common type of arg flags in the kernel? Could be an argument to be made there I guess). > But I just verified that at least in the kmalloc_objs() mistake, sparse will > flag it, thanks to the __bitwise annotation. Would be better if compiler > did, but it makes the case for changing gfp_t smaller if it was too > disruptive (it likely would be). Yeah I think it would be very disruptive indeed. A thought I'll forward to Roman - we should try having Sashiko[1] run Sparse and read the output, if it doesn't already. [1] https://lwn.net/Articles/1063292/
On Thu, Mar 19, 2026 at 04:03:23PM +0000, Brendan Jackman wrote:
> As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is
> probably not needed for 32-bit. This offers a way out of the GFP flag
> scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit
> machines, while leaving it 32-bit on 32-bit machines.
Ugh. This grows struct xarray:
struct xarray {
spinlock_t xa_lock;
/* private: The rest of the data structure is not to be used directly. */
gfp_t xa_flags;
void __rcu * xa_head;
};
which grows a lot of key data structures.
It would probably have been good for you to have run pahole before/after
this change and diff the results.
Now, you're probably saying "But this makes no damn sense, why on earth
is xa_flags of type gfp_t?" And the short answer is "because the radix
tree has a ridiculous API". But you'll learn all about it with your
new patch in this series which converts xa_flags from being gfp_t to a
plain unsigned int ;-)
On Thu Mar 19, 2026 at 4:56 PM UTC, Matthew Wilcox wrote:
> On Thu, Mar 19, 2026 at 04:03:23PM +0000, Brendan Jackman wrote:
>> As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is
>> probably not needed for 32-bit. This offers a way out of the GFP flag
>> scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit
>> machines, while leaving it 32-bit on 32-bit machines.
>
> Ugh. This grows struct xarray:
>
> struct xarray {
> spinlock_t xa_lock;
> /* private: The rest of the data structure is not to be used directly. */
> gfp_t xa_flags;
> void __rcu * xa_head;
> };
>
> which grows a lot of key data structures.
>
> It would probably have been good for you to have run pahole before/after
> this change and diff the results.
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.
> Now, you're probably saying "But this makes no damn sense, why on earth
> is xa_flags of type gfp_t?" And the short answer is "because the radix
> tree has a ridiculous API". But you'll learn all about it with your
> new patch in this series which converts xa_flags from being gfp_t to a
> plain unsigned int ;-)
Hm... so Can We Just™ turn:
#define radix_tree_root xarray
... into ...
struct radix_tree_root {
struct xarray xarray;
gfp_t gfp;
};
...? Or do we actually need to find a way to keep the radix_tree_root
from growing too? If so, given that (IIUC?) the radix-tree API is soft
deprecated, I guess we can be pretty simple-minded about it and just
define a fixed set of the GFP flag values people use for this:
enum radix_tree_gfp {
RADIX_TREE_GFP_KERNEL,
...
RADIX_TREE_GFP_KERNEL_NOWARN,
};
const gfp_t radix_tree_gfps[] = {
[RADIX_TREE_GFP_KERNEL] = GFP_KERNEL,
...
[RADIX_TREE_GFP_KERNEL_NOWARN] = GFP_KERNEL | __GFP_NOWARN,
};
Would that make sense?
---
struct acpi_device_bus_id | +8
struct address_space | +16
struct amd_iommu_viommu | +16
struct auxiliary_device | +8
struct bdev_inode | +16
struct blkcg | +8
struct cgroup_subsys | +8
struct chain_allocator | +8
struct compact_control | +8
struct debugfs_inode_info | +16
struct dma_device | +8
struct dmar_domain | +8
struct drm_conn_prop_enum_list | +8
struct drm_device | +32
struct drm_file | +16
struct drm_i915_file_private | +24
struct drm_i915_gem_object | +24
struct drm_i915_private | +40
struct drm_master | +24
struct drm_mode_config | +24
struct dw_dma | +8
struct ethtool_netdev_state | +8
struct ext4_inode_info | +16
struct fsnotify_group | +8
struct gendisk | +8
struct hsu_dma | +8
struct hugetlbfs_inode_info | +16
struct i915_gem_context | +8
struct i915_gem_object_page_iter | +8
struct i915_perf | +8
struct ida | +8
struct idr | +8
struct ieee80211_if_nan | +8
struct ieee80211_local | +8
struct inet_connection_sock | +16
struct inet_sock | +16
struct inode | +16
struct inotify_group_private_data | +8
struct __intel_generic_device | +32
struct intel_gt | +24
struct intel_guc | +24
struct intel_iommu | +8
struct intel_uc | +24
struct iommufd_viommu | +8
struct iommu_group | +8
struct ipc_ids | +8
struct irq_domain | +8
struct iso_inode_info | +16
struct kernfs_root | +8
struct kmem_cache | +8
struct kvm | +32
struct kvm_arch | +24
struct kvm_mmu_memory_cache | +8
struct kvm_vcpu | +40
struct kvm_vcpu_arch | +40
struct loop_device | +8
struct mei_aux_device | +8
struct migration_target_control | +8
struct mqueue_inode_info | +16
struct msdos_inode_info | +16
struct msi_dev_domain | +8
struct msi_device_data | +8
struct net_devmem_dmabuf_binding | +8
struct netfs_inode | +16
struct netlink_sock | +16
struct nfs_inode | +16
struct nfs_net | +8
struct objpool_head | +8
struct oom_control | +8
struct p9_client | +16
struct partial_context | +8
struct phy_link_topology | +8
struct proc_inode | +16
struct protection_domain | +8
struct pts_fs_info | +8
struct raw6_sock | +64
struct regmap | +8
struct rethook | +8
struct rpc_inode | +16
struct sctp_sock | +16
struct serial_ctrl_device | +8
struct shmem_inode_info | +16
struct shrink_control | +8
struct snd_card | +16
struct sock | +16
struct swnode | +8
struct tcf_block | +8
struct tcf_idrinfo | +8
struct tcf_net | +8
struct tg3_dev_id | +4
struct thermal_zone_device | +8
struct trace_event_raw_dma_alloc_class | +8
struct trace_event_raw_dma_alloc_sgt | +8
struct tracefs_inode | +16
struct ttm_bo_swapout_walk | +8
struct v9fs_inode | +16
struct virtio_gpu_device | +16
struct virtio_pci_admin_vq | +8
struct virtio_pci_device | +8
struct vmap_block_queue | +8
struct worker_pool | +8
struct xarray | +8
struct xhci_stream_info | +8
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. There's one in struct sock too. 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.
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?
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).
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.
© 2016 - 2026 Red Hat, Inc.