fs,mm: add kmem_cache_create_rcu()
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. So here's a
proposal.
I was hoping to get something to this effect into v6.12.
Thanks!
Christian
To: Vlastimil Babka <vbabka@suse.cz>
To: Jens Axboe <axboe@kernel.dk>,
To: "Paul E. McKenney" <paulmck@kernel.org>
To: Roman Gushchin <roman.gushchin@linux.dev>
To: Jann Horn <jannh@google.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
To: Mike Rapoport <rppt@kernel.org>
To: linux-mm@kvack.org
Cc: Christian Brauner <brauner@kernel.org>,
Cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
---
Changes in v3:
- Check for alignment of freeptr.
- Minor documentation fixes.
- Link to v2: https://lore.kernel.org/r/20240827-work-kmem_cache-rcu-v2-0-7bc9c90d5eef@kernel.org
Changes in v2:
- Export freeptr_t (Mike Rapoport)
- Remove boolean.
- Various other fixes
- Link to v1: https://lore.kernel.org/r/20240826-okkupieren-nachdenken-d88ac627e9bc@brauner
--- b4-submit-tracking ---
# This section is used internally by b4 prep for tracking purposes.
{
"series": {
"revision": 3,
"change-id": "20240827-work-kmem_cache-rcu-f97e35600cc6",
"prefixes": [],
"base-branch": "vfs.misc",
"history": {
"v1": [
"20240826-okkupieren-nachdenken-d88ac627e9bc@brauner"
],
"v2": [
"20240827-work-kmem_cache-rcu-v2-0-7bc9c90d5eef@kernel.org"
]
}
}
}