Re: [RFC] [PATCH 1/8] inode_diet: Replace inode.u.generic_ip withinode.i_private

[Steven Whitehouse]

Hi,

On Tue, 2006-06-20 at 13:45 +0200, Arnd Bergmann wrote:
> On Tuesday 20 June 2006 11:43, Steven Whitehouse wrote:
> > As a further suggestion, I wonder do we really need i_private at all?
> > Since we have sb->s_op->alloc_inode and inode->i_sb->s_op->destroy_inode
> > if all filesystems did something along the following lines:
> > 
> > struct myfs_inode {
> >         struct inode i_inode;
> >         ...
> > };
> > 
> > #define MYFS_I(inode) container_of((inode), struct myfs_inode, i_inode)
> > 
> > then it would seem that i_private is redundant. If there is a file
> > system which does genuinely need a pointer here (if indeed such a
> > filesystem does exist, I haven't actually checked that) then a pointer
> > can just be added as the one single other member of (in my example)
> > struct myfs_inode.
> > 
> That would mean that all file systems need to implement ->alloc_inode,
> which in turn need slab caches that eat consume memory even when
> the file system is not mounted.
> 
Yes, although I'm not sure that it would be as significant as the memory
saved by removing the pointer bearing in mind the relative numbers of
the structures that you'd expect to see in a "normal" working system. We
could also try and reduce this by creating a special inode cache which
would be shared by all filesystems which did still need just struct
inode + private pointer for example.

What you do gain though is (on umount of a filesystem) a much greater
likelihood of being able to reclaim the memory which was being used by
the inodes of that particular filesystem (particularly so if you only
have a single mounted filesystem of a particular type). So hopefully
having a separate slab cache per fstype would help reduce memory
fragmentation, and more than compensate for the difference.

In fact a number of filesystems already have slab caches for their own
private part of the inode anyway... I count 10 of those on my current
development box.

> Something as simple as nfsctl or devpts should not need that.
> 
> 	Arnd <><

Steve.


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