From: Linus Torvalds <torvalds@linux-foundation.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz>,
Harry Yoo <harry.yoo@oracle.com>,
linux-fsdevel@vger.kernel.org,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Mateusz Guzik <mguzik@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 00/15] kmem_cache instances with static storage duration
Date: Fri, 9 Jan 2026 19:33:41 -1000 [thread overview]
Message-ID: <CAHk-=wiibHkNcsvsVpQLCMNJOh-dxEXNqXUxfQ63CTqX5w04Pg@mail.gmail.com> (raw)
In-Reply-To: <20260110040217.1927971-1-viro@zeniv.linux.org.uk>
On Fri, 9 Jan 2026 at 18:01, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> There's an alternative approach applicable at least to the caches
> that are never destroyed, which covers a lot of them. No matter what,
> runtime_const for pointers is not going to be faster than plain &,
> so if we had struct kmem_cache instances with static storage duration, we
> would be at least no worse off than we are with runtime_const variants.
I like it. Much better than runtime_const for these things.
That said, I don't love the commit messages. "turn xyzzy
static-duration" reads very oddly to me, and because I saw the emails
out of order originally it just made me go "whaa?"
So can we please explain this some more obvious way. Maybe just "Make
xyz be statically allocated". Yes, I'm nitpicking, but I feel like
explaining core patches is worth the effort.
And maybe that's for the sad reason that I read more explanations than
code these days '/
Linus
next prev parent reply other threads:[~2026-01-10 5:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-10 4:02 Al Viro
2026-01-10 4:02 ` [RFC PATCH 01/15] static kmem_cache instances for core caches Al Viro
2026-01-10 5:40 ` Matthew Wilcox
2026-01-10 6:23 ` Al Viro
2026-01-10 4:02 ` [RFC PATCH 02/15] allow static-duration kmem_cache in modules Al Viro
2026-01-10 4:02 ` [RFC PATCH 03/15] make mnt_cache static-duration Al Viro
2026-01-10 4:02 ` [RFC PATCH 04/15] turn thread_cache static-duration Al Viro
2026-01-10 4:02 ` [RFC PATCH 05/15] turn signal_cache static-duration Al Viro
2026-01-10 4:02 ` [RFC PATCH 06/15] turn bh_cachep static-duration Al Viro
2026-01-10 4:02 ` [RFC PATCH 07/15] turn dentry_cache static-duration Al Viro
2026-01-10 4:02 ` [RFC PATCH 08/15] turn files_cachep static-duration Al Viro
2026-01-10 4:02 ` [RFC PATCH 09/15] make filp and bfilp caches static-duration Al Viro
2026-01-10 4:02 ` [RFC PATCH 10/15] turn sighand_cache static-duration Al Viro
2026-01-10 4:02 ` [RFC PATCH 11/15] turn mm_cachep static-duration Al Viro
2026-01-10 4:02 ` [RFC PATCH 12/15] turn task_struct_cachep static-duration Al Viro
2026-01-10 4:02 ` [RFC PATCH 13/15] turn fs_cachep static-duration Al Viro
2026-01-10 4:02 ` [RFC PATCH 14/15] turn inode_cachep static-duration Al Viro
2026-01-10 4:02 ` [RFC PATCH 15/15] turn ufs_inode_cache static-duration Al Viro
2026-01-10 5:33 ` Linus Torvalds [this message]
2026-01-10 6:16 ` [RFC PATCH 00/15] kmem_cache instances with static storage duration Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHk-=wiibHkNcsvsVpQLCMNJOh-dxEXNqXUxfQ63CTqX5w04Pg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=harry.yoo@oracle.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mguzik@gmail.com \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox