Messages in this thread | | | From | Steven Whitehouse <> | Date | Tue, 20 Jun 2006 13:34:09 +0100 | Subject | Re: [RFC] [PATCH 1/8] inode_diet: Replace inode.u.generic_ip with inode.i_private |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |