Re: [PATCH] fs: shave 8 bytes off of struct inode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux