diff options
| author | Nick Piggin <npiggin@kernel.dk> | 2011-01-07 07:49:56 +0100 |
|---|---|---|
| committer | Nick Piggin <npiggin@kernel.dk> | 2011-01-07 07:50:28 +0100 |
| commit | 44a7d7a878c9cbb74f236ea755b25b6b2e26a9a9 (patch) | |
| tree | d4630a38c0d683a7e1b8823d7971753719b8a54d /fs | |
| parent | fs: dcache reduce branches in lookup path (diff) | |
| download | linux-44a7d7a878c9cbb74f236ea755b25b6b2e26a9a9.tar.xz linux-44a7d7a878c9cbb74f236ea755b25b6b2e26a9a9.zip | |
fs: cache optimise dentry and inode for rcu-walk
Put dentry and inode fields into top of data structure. This allows RCU path
traversal to perform an RCU dentry lookup in a path walk by touching only the
first 56 bytes of the dentry.
We also fit in 8 bytes of inline name in the first 64 bytes, so for short
names, only 64 bytes needs to be touched to perform the lookup. We should
get rid of the hash->prev pointer from the first 64 bytes, and fit 16 bytes
of name in there, which will take care of 81% rather than 32% of the kernel
tree.
inode is also rearranged so that RCU lookup will only touch a single cacheline
in the inode, plus one in the i_ops structure.
This is important for directory component lookups in RCU path walking. In the
kernel source, directory names average is around 6 chars, so this works.
When we reach the last element of the lookup, we need to lock it and take its
refcount which requires another cacheline access.
Align dentry and inode operations structs, so members will be at predictable
offsets and we can group common operations into head of structure.
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Diffstat (limited to 'fs')
| -rw-r--r-- | fs/dcache.c | 2 |
1 files changed, 0 insertions, 2 deletions
diff --git a/fs/dcache.c b/fs/dcache.c index f9693da3efbd..07d1f6862dc7 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -83,8 +83,6 @@ EXPORT_SYMBOL(dcache_inode_lock); static struct kmem_cache *dentry_cache __read_mostly; -#define DNAME_INLINE_LEN (sizeof(struct dentry)-offsetof(struct dentry,d_iname)) - /* * This is the single most critical data structure when it comes * to the dcache: the hashtable for lookups. Somebody should try |