summaryrefslogtreecommitdiffstats
path: root/ipc
diff options
context:
space:
mode:
authorTheodore Ts'o <tytso@mit.edu>2009-06-08 15:22:25 -0400
committerAl Viro <viro@zeniv.linux.org.uk>2009-06-17 00:36:35 -0400
commit210ad6aedb332e73167ece5af9bd47f0da8c2aca (patch)
tree29e463655148987f3bce2510d94e36da7dd07176 /ipc
parent9c64daff9d5afb102dfe64a26829e26725538e58 (diff)
downloadlinux-210ad6aedb332e73167ece5af9bd47f0da8c2aca.tar.bz2
ext4: avoid unnecessary spinlock in critical POSIX ACL path
If a filesystem supports POSIX ACL's, the VFS layer expects the filesystem to do POSIX ACL checks on any files not owned by the caller, and it does this for every single pathname component that it looks up. That obviously can be pretty expensive if the filesystem isn't careful about it, especially with locking. That's doubly sad, since the common case tends to be that there are no ACL's associated with the files in question. ext4 already caches the ACL data so that it doesn't have to look it up over and over again, but it does so by taking the inode->i_lock spinlock on every lookup. Which is a noticeable overhead even if it's a private lock, especially on CPU's where the serialization is expensive (eg Intel Netburst aka 'P4'). For the special case of not actually having any ACL's, all that locking is unnecessary. Even if somebody else were to be changing the ACL's on another CPU, we simply don't care - if we've seen a NULL ACL, we might as well use it. So just load the ACL speculatively without any locking, and if it was NULL, just use it. If it's non-NULL (either because we had a cached entry, or because the cache hasn't been filled in at all), it means that we'll need to get the lock and re-load it properly. (This commit was ported from a patch originally authored by Linus for ext3.) Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'ipc')
0 files changed, 0 insertions, 0 deletions