linux-kernel - fs: why is lru_lock cachline_aligned_in_smp in the middle of super

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-next>] [day] [month] [year] [list]

Message-ID: <1313411164.1954.18.camel@castor.rsk>
Date:	Mon, 15 Aug 2011 13:26:03 +0100
From:	Richard Kennedy <richard@....demon.co.uk>
To:	Dave Chinner <dchinner@...hat.com>
Cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Matthew Wilcox <matthew@....cx>
Subject: fs: why is lru_lock cachline_aligned_in_smp in the middle of
 super_block?

In commit 09cc9fc7a7c3d872065426d7fb0f0ad6d3eb90fc lru_lock was added to
super_block defined as :-

spinlock_t	s_inode_lru_lock ____cacheline_aligned_in_smp;

Due unfortunate placement in my 64 bit config, gcc has to add a lot of
padding to super_block to honour this.
I get 60 bytes before lru_lock & 32 bytes at the end of the structure.

So I was wondering what access pattern are you trying to avoid ?
And could it be prevented by just moving lru_lock and friends to
somewhere else in the structure? 

Even if they were at the end and still cacheline aligned then we would
not have that nearly empty cacheline in the middle.

If they are in the best place then at least add a comment to explain why
this needs to be cacheline aligned?

regards
Richard

--
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/