On Wed, Jun 21, 2006 at 08:42:17AM -0600, Brian F. G. Bidulock wrote:
> > 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....
>
> Can you grep inode_cache /proc/slabinfo to see whether you saved any
> memory at all?
I've been doing this continuously as I do my patches, and, yes, we're
definitely saving memory. How much memory depends on the
configuration. In particular, some people may not realize how much
memory CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_MUTEXES, et. al. consume.
They can make the difference between 300-odd bytes and 500-odd bytes
for the base struct inode.
Also, struct inode is part of a number of different
filesystem-specific inodes, so as we gradually slim down the inode, we
can sometimes win with one filsystem more than others.
But just so people can see the results, here they are on a UML system:
BEFORE AFTER
name size obj/slab size obj/slab
isofs_inode_cache 308 13 280 14
fat_inode_cache 332 12 304 13
ext2_inode_cache 388 10 360 11
ext3_inode_cache 424 9 396 10
reiser_inode_cache 356 11 328 12
shmem_inode_cache 372 10 344 11
proc_inode_cache 296 13 268 14
inode_cache 280 14 252 15
By going from 280 to 252 bytes, we've achieved a net savings of 10% on
struct inode, which is definitely not bad. Is there more work to be
done? Sure. But we need to take the first step.
- Ted
-
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]
