| Message ID | 20240828-work-kmem_cache-rcu-v3-0-5460bc1f09f6@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | fs,mm: add kmem_cache_create_rcu() | expand |
On Wed, 28 Aug 2024 12:56:22 +0200, Christian Brauner wrote: > When a kmem cache is created with SLAB_TYPESAFE_BY_RCU the free pointer > must be located outside of the object because we don't know what part of > the memory can safely be overwritten as it may be needed to prevent > object recycling. > > That has the consequence that SLAB_TYPESAFE_BY_RCU may end up adding a > new cacheline. This is the case for .e.g, struct file. After having it > shrunk down by 40 bytes and having it fit in three cachelines we still > have SLAB_TYPESAFE_BY_RCU adding a fourth cacheline because it needs to > accomodate the free pointer and is hardware cacheline aligned. > > [...] Applied to the vfs.file branch of the vfs/vfs.git tree. Patches in the vfs.file branch should appear in linux-next soon. Please report any outstanding bugs that were missed during review in a new review to the original patch series allowing us to drop it. It's encouraged to provide Acked-bys and Reviewed-bys even though the patch has now been applied. If possible patch trailers will be updated. Note that commit hashes shown below are subject to change due to rebase, trailer updates or similar. If in doubt, please check the listed branch. tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git branch: vfs.file [1/3] mm: remove unused root_cache argument https://git.kernel.org/vfs/vfs/c/a85ba9858175 [2/3] mm: add kmem_cache_create_rcu() https://git.kernel.org/vfs/vfs/c/ba8108d69e5b [3/3] fs: use kmem_cache_create_rcu() https://git.kernel.org/vfs/vfs/c/d1e381aa30cb
When a kmem cache is created with SLAB_TYPESAFE_BY_RCU the free pointer must be located outside of the object because we don't know what part of the memory can safely be overwritten as it may be needed to prevent object recycling. That has the consequence that SLAB_TYPESAFE_BY_RCU may end up adding a new cacheline. This is the case for .e.g, struct file. After having it shrunk down by 40 bytes and having it fit in three cachelines we still have SLAB_TYPESAFE_BY_RCU adding a fourth cacheline because it needs to accomodate the free pointer and is hardware cacheline aligned. I tried to find ways to rectify this as struct file is pretty much everywhere and having it use less memory is a good thing. Before this series cat /proc/slabinfo: filp 1198 1248 256 32 2 : tunables 0 0 0 : slabdata 39 39 0 ^^^ After this series cat /proc/slabinfo: filp 1323 1323 192 21 1 : tunables 0 0 0 : slabdata 63 63 0 ^^^ I was hoping to get something to this effect into v6.12. Thanks! Christian Signed-off-by: Christian Brauner <brauner@kernel.org> --- Changes in v3: - Check for alignment of freeptr. - Minor documentation fixes. - Fix freeptr validation. - Link to v2: https://lore.kernel.org/r/20240827-work-kmem_cache-rcu-v2-0-7bc9c90d5eef@kernel.org Changes in v2: - Export freeptr_t. - Remove boolean. - Various other fixes - Link to v1: https://lore.kernel.org/r/20240826-okkupieren-nachdenken-d88ac627e9bc@brauner --- Christian Brauner (3): mm: remove unused root_cache argument mm: add kmem_cache_create_rcu() fs: use kmem_cache_create_rcu() fs/file_table.c | 6 +-- include/linux/fs.h | 2 + include/linux/slab.h | 9 ++++ mm/slab.h | 2 + mm/slab_common.c | 139 ++++++++++++++++++++++++++++++++++++--------------- mm/slub.c | 20 +++++--- 6 files changed, 127 insertions(+), 51 deletions(-) --- base-commit: 766508e7e2c5075eb744cb29b8cef6fa835b0344 change-id: 20240827-work-kmem_cache-rcu-f97e35600cc6