[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4C7001C9.7050200@redhat.com>
Date: Sat, 21 Aug 2010 11:41:45 -0500
From: Eric Sandeen <sandeen@...hat.com>
To: Richard Kennedy <richard@....demon.co.uk>
CC: "Theodore Ts'o" <tytso@....edu>,
lkml <linux-kernel@...r.kernel.org>,
Andreas Dilger <adilger.kernel@...ger.ca>,
linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4: remove alignment padding from ext4_inode_info on
64 bit builds
Richard Kennedy wrote:
> On Fri, 2010-08-20 at 15:11 -0500, Eric Sandeen wrote:
>> Richard Kennedy wrote:
>>> Reorder structure ext4_inode_info to remove 16 bytes of alignment
>>> padding on 64 bit builds. This shrinks its size from 904 to 888 bytes
>>> with (CONFIG_EXT4_S_XATTR=y && CONFIG_QUOTA=n).
>>>
>>> This will allow this structure to use one fewer cache lines.
>>>
>>> Also change type of i_delalloc_reserved_flag to bool to better reflect
>>> its usage.
>>>
>>> compiled & tested on x86_64
>>
>> Looks good to me; there is still a bit of padding at the end:
>>
>> qsize_t i_reserved_quota; /* 864 8 */
>> struct list_head i_completed_io_list; /* 872 16 */
>> spinlock_t i_completed_io_lock; /* 888 4 */
>>
>> /* XXX 4 bytes hole, try to pack */
>>
>> /* --- cacheline 14 boundary (896 bytes) --- */
>> ext4_io_end_t * cur_aio_dio; /* 896 8 */
>> tid_t i_sync_tid; /* 904 4 */
>> tid_t i_datasync_tid; /* 908 4 */
>>
>>
>> but it wouldn't save a cacheline anyway...
>>
>> -Eric
>>
> Thanks Eric, yes there is padding but we don't have anything to fill the
> hole with :(
>
> If it becomes important to save space, i_state_flags seem to be unused
> in ext4 so we could possibly drop that.
Actually it is used, it's just expertly hidden in:
EXT4_INODE_BIT_FNS(state, state_flags):
#define EXT4_INODE_BIT_FNS(name, field) \
static inline int ext4_test_inode_##name(struct inode *inode, int bit) \
{ \
return test_bit(bit, &EXT4_I(inode)->i_##field); \
} \
etc..
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists