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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
