fs: why is lru_lock cachline_aligned_in_smp in the middle ofsuper_block?
From: Richard Kennedy
Date: Mon Aug 15 2011 - 08:26:12 EST
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?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/