Richard Kennedy wrote:
quoted text
> 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

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/