[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060914183325.GU6441@schatzie.adilger.int>
Date: Thu, 14 Sep 2006 12:33:25 -0600
From: Andreas Dilger <adilger@...sterfs.com>
To: Jörn Engel <joern@...nheim.fh-wedel.de>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] Alignment of fields in struct dentry
On Sep 14, 2006 12:50 +0200, J�rn Engel wrote:
> > After taking a look at struct dentry, Arnd noted an alignment
> > problem.
> > On 64bit architectures, the first three take 12 bytes and d_inode is
> > not naturally aligned, so it can be aligned to byte 16.
>
> struct dentry {
> atomic_t d_count;
> unsigned int d_flags; /* protected by d_lock */
> spinlock_t d_lock; /* per dentry lock */
> - struct inode *d_inode; /* Where the name belongs to - NULL is
> - * negative */
> + int d_mounted;
> /*
> * The next three fields are touched by __d_lookup. Place them here
> * so they all fit in a cache line.
> @@ -93,6 +96,8 @@ struct dentry {
> struct dentry *d_parent; /* parent directory */
> struct qstr d_name;
>
> + struct inode *d_inode; /* Where the name belongs to - NULL is
I think it makes sense to keep d_inode in the first part of the dentry
always, because it is by far the most referenced field in the dentry,
along with the critical fields from prune_dcache(), shrink_dcache_anon(),
dget(), dput(), d_lookup().
While not totally accurate in terms of runtime frequency of use, the counts
in the code:
fs/*.[ch] fs/*/*.[ch] size32 size64 prune_dc shrk_dc_anon d_lookup
d_inode 384 2131 4 8
d_lock 104 529 4 4 1 2
d_count 18 66 4 4 1 2
d_lru 18 18 4_ 8 1 1
d_hash 37 154 4 8_ 2 1
d_name 73 908 12_ 16 1
d_flags 26 104 4 4 2
d_mounted 7 7 4 4
d_parent 40 231 4 8_ 2
d_op 37 269 4 8
d_rcu/d_child 3+22 3+45 8 16
The '_' are potential cacheline boundaries.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists