From: Linus Torvalds <torvalds@linux-foundation.org>
To: Mateusz Guzik <mjguzik@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Jan Kara <jack@suse.cz>,
Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: generic_permission() optimization
Date: Sat, 12 Apr 2025 13:22:38 -0700 [thread overview]
Message-ID: <CAHk-=wh+pk72FM+a7PoW2s46aU9OQZrY-oApMZSUH0Urg9bsMA@mail.gmail.com> (raw)
In-Reply-To: <CAGudoHGxr5gYb0JqPqF_J0MoSAb_qqoF4gaJMEdOhp51yobbLw@mail.gmail.com>
On Sat, 12 Apr 2025 at 09:26, Mateusz Guzik <mjguzik@gmail.com> wrote:
>
> I plopped your snippet towards the end of __ext4_iget:
That's literally where I did the same thing, except I put it right after the
brelse(iloc.bh);
line, rather than before as you did.
And it made no difference for me, but I didn't try to figure out why.
Maybe some environment differences? Or maybe I just screwed up my
testing...
As mentioned earlier in the thread, I had this bi-modal distribution
of results, because if I had a load where the *non*-owner of the inode
looked up the pathnames, then the ACL information would get filled in
when the VFS layer would do the lookup, and then once the ACLs were
cached, everything worked beautifully.
But if the only lookups of a path were done by the owner of the inodes
(which is typical for at least my normal kernel build tree - nothing
but my build will look at the files, and they are obviously always
owned by me) then the ACL caches will never be filled because there
will never be any real ACL lookups.
And then rather than doing the nice efficient "no ACLs anywhere, no
need to even look", it ends up having to actually do the vfsuid
comparison for the UID equality check.
Which then does the extra accesses to look up the idmap etc, and is
visible in the profiles due to that whole dance:
/* Are we the owner? If so, ACL's don't matter */
vfsuid = i_uid_into_vfsuid(idmap, inode);
if (likely(vfsuid_eq_kuid(vfsuid, current_fsuid()))) {
even when idmap is 'nop_mnt_idmap' and it is reasonably cheap. Just
because it ends up calling out to different functions and does extra
D$ accesses to the inode and the suberblock (ie i_user_ns() is this
return inode->i_sb->s_user_ns;
so just to *see* that it's nop_mnt_idmap takes effort.
One improvement might be to cache that 'nop_mnt_idmap' thing in the
inode as a flag.
But it would be even better if the filesystem just initializes the
inode at inode read time to say "I have no ACL's for this inode" and
none of this code will even trigger.
Linus
next prev parent reply other threads:[~2025-04-12 20:22 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-31 4:16 generic_permission() optimization Linus Torvalds
2024-10-31 6:05 ` Al Viro
2024-10-31 6:42 ` Linus Torvalds
2024-10-31 18:14 ` Linus Torvalds
2024-10-31 22:28 ` Al Viro
2024-10-31 22:34 ` Linus Torvalds
2024-11-01 1:17 ` Linus Torvalds
2024-11-01 1:27 ` Al Viro
2024-11-01 13:15 ` Christian Brauner
2024-10-31 13:02 ` Christian Brauner
2024-10-31 19:04 ` Linus Torvalds
2024-10-31 22:02 ` Linus Torvalds
2024-10-31 22:31 ` Linus Torvalds
2024-11-07 19:54 ` Linus Torvalds
2024-11-07 22:22 ` Mateusz Guzik
2024-11-07 22:49 ` Linus Torvalds
2025-04-12 16:26 ` Mateusz Guzik
2025-04-12 20:22 ` Linus Torvalds [this message]
2025-04-14 10:21 ` Christian Brauner
2025-04-16 13:17 ` [PATCH RFC 0/3] mnt_idmapping: avoid pointer chase & inline low-level helpers Christian Brauner
2025-04-16 13:17 ` [PATCH RFC 1/3] inode: add fastpath for filesystem user namespace retrieval Christian Brauner
2025-04-16 13:49 ` Mateusz Guzik
2025-04-16 14:14 ` Christian Brauner
2025-04-22 10:37 ` Jan Kara
2025-04-22 13:33 ` Mateusz Guzik
2025-04-22 14:05 ` Christian Brauner
2025-04-16 13:17 ` [PATCH RFC 2/3] mnt_idmapping: add struct mnt_idmap to header Christian Brauner
2025-04-16 13:17 ` [PATCH RFC 3/3] mnt_idmapping: inline all low-level helpers Christian Brauner
2025-04-16 15:04 ` Linus Torvalds
2025-04-22 9:28 ` Christian Brauner
2025-04-12 21:52 ` generic_permission() optimization Theodore Ts'o
2025-04-12 22:36 ` Linus Torvalds
2025-04-12 23:12 ` Linus Torvalds
2025-04-12 23:55 ` Theodore Ts'o
2025-04-13 9:41 ` Mateusz Guzik
2025-04-13 12:40 ` Theodore Ts'o
2025-04-13 12:52 ` Mateusz Guzik
2025-04-13 17:29 ` Theodore Ts'o
2025-11-05 11:50 ` Mateusz Guzik
2025-11-05 11:51 ` Mateusz Guzik
2025-11-05 13:37 ` Jan Kara
2025-11-17 11:42 ` Mateusz Guzik
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-=wh+pk72FM+a7PoW2s46aU9OQZrY-oApMZSUH0Urg9bsMA@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mjguzik@gmail.com \
--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;
as well as URLs for NNTP newsgroup(s).