On Tue, Jun 12, 2018 at 5:24 PM, Jan Kara <jack@xxxxxxx> wrote:
> On Tue 12-06-18 14:11:30, Amir Goldstein wrote:
>> Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
>> ---
>>
>> Linus,
>>
>> I tried to find some space to cram i_generation in case
>> I get rid of i_fsnotify_mask, but stumbled on a possible
>> "lossless compression".
>>
>> Any caveats with this change?
>
> One concern I'd have is that i_blkbits is used relatively frequently (e.g.
> for block device access) and 1-byte fetch can be slower than 4-byte fetch
> on some architectures if I'm not mistaken. I'm not sure how big problem
> that would be through.
That's what I suspected. However, if using 1-byte access for i_write_hint
is non controversial(?) then by re-arranging i_write_hint, I get the 4-byte
hole that I need to move i_generation into (in place of i_write_hint):
unsigned short i_bytes;
+ u8 i_write_hint;
unsigned int i_blkbits;
- enum rw_hint i_write_hint;
blkcnt_t i_blocks;
>
> But if you're looking at reducing struct inode size, it appears we can save
> one long by reorganizing struct address_space - there's currently 4-byte
> hole after i_mmap_writeable and after wb_err.
>
That is not my goal, I just wanted to ask a naiive question, but seems
that Matthew already has the struct address_space hole covered..
Thanks,
Amir.
