Re: [RESEND PATCH] cred: separate the refcount from frequently read fields
From: Paul Moore <paul@paul-moore.com>
Date: 2024-08-22 20:58:57
Also in:
lkml
On Thu, Aug 22, 2024 at 9:15 AM Mateusz Guzik [off-list ref] wrote:
The refcount shares the cacheline with uid, gid and other frequently read fields. Said counter gest modified a lot (for example every time a file is closed or opened) in turn causing avoidable bounces when another thread tries to do permission checks. Said bouncing can be avoided without growing the struct by reordering the fields -- keyring (enabled by default) is comparatively rarely used and can suffer bouncing instead. An additional store is performed to clear the non_rcu flag. Since the flag is rarely set (a special case in the access(2) system call) and transitions at most once, it can get placed in a read-mostly area and is only conditionally written to. With this in place regular permission checks no longer bounce cachelines in face of refcount changes. Validated with a simple test where one thread opens and closes a file (dirtying creds twice), while another keeps re-reading *another* file in a loop (ops/s): before: 4353763 after: 4742792 (+9%) Signed-off-by: Mateusz Guzik <redacted> --- This is a resend with a reworded commit message and added Linus since he wrote the non_rcu thing. Note each process has its on creds, so this is not causing bounces globally. Even so, there is stuff I plan to do in the area and this patch can be considered prep (only one store to non_rcu). I'll also note I don't see a way to *whack* non_rcu either. :) 0 rush fs/open.c | 2 +- include/linux/cred.h | 31 +++++++++++++++---------------- kernel/cred.c | 6 +++--- 3 files changed, 19 insertions(+), 20 deletions(-)
[NOTE: no comment on the patch context yet, just process comments below] FWIW, I really haven't commented on these last couple of cred patches mostly because I've been assuming someone else would emerge from the shadows as the cred maintainer, or at least someone who felt strongly enough about these changes would merge them. Unfortunately, I worry that isn't really going to happen and I'd hate for some of the cred improvements to die on the lists. If no one starts grabbing your cred patches I can start taking cred patches as part of the LSM tree, I've done it a couple of times in the past and Linus didn't seem to mind. -- paul-moore.com