This is the second versoin of patches to reduce the size of struct
inode. I've taken into account comments to remove super.st_blksize,
and simply requiring filesystems to override getattr if they care to
use something other than the stock PAGE_CACHE_SIZE for st_blksize
(which should be correct given that most filesystems are using
generic_file_read/write).
Unfortunately, since these structures are used by a large amount of
kernel code, some of the patches are quite involved, and/or will
require a lot of auditing and code review, for "only" 4 or 8 bytes at
a time (maybe more on 64-bit platforms). However, since there are
many, many copies of struct inode all over the kernel, even a small
reduction in size can have a large beneficial result, and as the old
Chinese saying goes, a journey of thousand miles begins with a single
step....
What else remains to be done? There are a large number of fields in
struct inode which are never populated unless the inode is open, and
those should get moved into another structure which is populated only
when needed. There are a large number of inodes which are read into
memory only because stat(2) was called on them (thanks to things like
color ls, et. al).
Linus has suggested moving the i_data structure out to a separate
structure, again because there are many inodes which do not have any
pages cached in the page cache. The challenge with this a huge number
of codepaths assume that i_mapping is always non-NULL. But, i_data is
*huge* so the benefits of not having it taking up memory would make
this a high-return activity.
Another possibility is moving i_size into the file-specific area of
the union, which would save 8 bytes. However there are a largish
number block device drivers that seem to have hijacked i_size to store
the blocksize(!?!) of the device, and that should really be done in a
bdev-specific structure. Untangling this will be somewhat
challenging, but should be doable.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
