lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ