linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH RFC 0/6] slab: add kmem_cache_setup()
@ 2024-09-02 15:31 Christian Brauner
  2024-09-02 15:31 ` [PATCH RFC 1/6] slab: introduce kmem_cache_setup() Christian Brauner
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: Christian Brauner @ 2024-09-02 15:31 UTC (permalink / raw)
  To: Vlastimil Babka, Jens Axboe, Jann Horn, Linus Torvalds
  Cc: linux-mm, Christian Brauner

Hey,

As discussed last week the various kmem_cache_*() functions should be
replaced by a unified function that is based around a struct, with only
the basic parameters passed separately.

Vlastimil already hinted that he would like to keep core parameters out
of the struct: name, object size, and flags. I personally don't care
much and would not object to moving everything into the struct but
that's a matter of taste and I yield that decision power to the
maintainer.

Here's an RFC built for a kmem_cache_setup() based on struct
kmem_cache_args.

The choice of name is somewhat forced as kmem_cache_create() is taken
and the only way to reuse it would be to replace all users in one go.
Or to do a global sed/kmem_cache_create()/kmem_cache_create2()/g. And
then introduce kmem_cache_setup(). That doesn't strike me as a viable
option.

If we really cared about the *_create() suffix then an alternative might
be to do a sed/kmem_cache_setup()/kmem_cache_create()/g after every user
in the kernel is ported. I honestly don't think that's worth it but I
wanted to at least mention it to highlight the fact that this might lead
to a naming compromise.

From a cursory grep (and not excluding Documentation mentions) we will
have to replace 44 kmem_cache_create_usercopy() calls and about 463
kmem_cache_create() calls which makes for a bit above 500 calls to port
to kmem_cache_setup(). That'll probably be good work for people getting
into kernel development.

Anyway, I wanted to get an RFC out to get some rough agreement on what
the struct should look like, get some bikeshedding on the name done, and
what else needs to be massaged as part of this. I think that
cache_create() is the deepest we should stuff struct kmem_cache_args
into the bowels of slab.

Signed-off-by: Christian Brauner <brauner@kernel.org>
---
Christian Brauner (6):
      slab: introduce kmem_cache_setup()
      slab: port KMEM_CACHE() to kmem_cache_setup()
      slab: port KMEM_CACHE_USERCOPY() to kmem_cache_setup()
      file: port to kmem_cache_setup()
      slab: remove kmem_cache_create_rcu()
      io_uring: port to kmem_cache_setup()

 Documentation/core-api/memory-allocation.rst |  10 +-
 fs/file_table.c                              |  12 ++-
 include/linux/slab.h                         |  51 ++++++++---
 io_uring/io_uring.c                          |  15 +--
 mm/slab_common.c                             | 132 ++++++++++++---------------
 5 files changed, 121 insertions(+), 99 deletions(-)
---
base-commit: 6e016babce7c845ed015da25c7a097fa3482d95a
change-id: 20240902-work-kmem_cache_args-e9760972c7d4



^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2024-09-02 18:15 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-09-02 15:31 [PATCH RFC 0/6] slab: add kmem_cache_setup() Christian Brauner
2024-09-02 15:31 ` [PATCH RFC 1/6] slab: introduce kmem_cache_setup() Christian Brauner
2024-09-02 15:31 ` [PATCH RFC 2/6] slab: port KMEM_CACHE() to kmem_cache_setup() Christian Brauner
2024-09-02 15:31 ` [PATCH RFC 3/6] slab: port KMEM_CACHE_USERCOPY() " Christian Brauner
2024-09-02 15:31 ` [PATCH RFC 4/6] file: port " Christian Brauner
2024-09-02 15:31 ` [PATCH RFC 5/6] slab: remove kmem_cache_create_rcu() Christian Brauner
2024-09-02 15:31 ` [PATCH RFC 6/6] io_uring: port to kmem_cache_setup() Christian Brauner
2024-09-02 18:15 ` [PATCH RFC 0/6] slab: add kmem_cache_setup() Vlastimil Babka

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).