dentry cache uses sophisticated RCU technology (and prefetching if available)
but touches 2 cache lines per dentry during hlist lookup.
This patch moves d_hash in the same cache line than d_parent and d_name fields
so that :
1) One cache line is needed instead of two.
2) the hlist_for_each_rcu() prefetching has a chance to bring all the needed
data in advance, not only the part that includes d_hash.next.
I also changed one old comment that was wrong for 64bits.
A further optimisation would be to separate dentry in two parts, one that is
mostly read, and one writen (d_count/d_lock) to avoid false sharing on
SMP/NUMA but this would need different field placement depending on 32bits or
64bits platform.
with the patch this time :)
Signed-off-by: Eric Dumazet <[email protected]>
--- linux-2.6.13/include/linux/dcache.h 2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13-ed/include/linux/dcache.h 2005-09-01 17:22:32.000000000 +0200
@@ -88,8 +88,9 @@
* negative */
/*
* The next three fields are touched by __d_lookup. Place them here
- * so they all fit in a 16-byte range, with 16-byte alignment.
+ * so they all fit in a cache line.
*/
+ struct hlist_node d_hash; /* lookup hash list */
struct dentry *d_parent; /* parent directory */
struct qstr d_name;
@@ -103,7 +104,6 @@
void *d_fsdata; /* fs-specific data */
struct rcu_head d_rcu;
struct dcookie_struct *d_cookie; /* cookie, if any */
- struct hlist_node d_hash; /* lookup hash list */
int d_mounted;
unsigned char d_iname[DNAME_INLINE_LEN_MIN]; /* small names */
};
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|