Re: [RFC] [PATCH 1/8] inode_diet: Replace inode.u.generic_ip with inode.i_private
- From: Steven Whitehouse <steve@xxxxxxxxxxx>
- Date: Tue, 20 Jun 2006 13:34:09 +0100
Hi,
On Tue, 2006-06-20 at 13:45 +0200, Arnd Bergmann wrote:
On Tuesday 20 June 2006 11:43, Steven Whitehouse wrote:Yes, although I'm not sure that it would be as significant as the memory
As a further suggestion, I wonder do we really need i_private at all?That would mean that all file systems need to implement ->alloc_inode,
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.
which in turn need slab caches that eat consume memory even when
the file system is not mounted.
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/
- Follow-Ups:
- References:
- [RFC] [PATCH 0/8] Inode slimming
- From: Theodore Tso
- [RFC] [PATCH 1/8] inode_diet: Replace inode.u.generic_ip with inode.i_private
- From: Theodore Tso
- Re: [RFC] [PATCH 1/8] inode_diet: Replace inode.u.generic_ip with inode.i_private
- From: Steven Whitehouse
- Re: [RFC] [PATCH 1/8] inode_diet: Replace inode.u.generic_ip with inode.i_private
- From: Arnd Bergmann
- [RFC] [PATCH 0/8] Inode slimming
- Prev by Date: LibPATA/ATA Errors Continue - Will there be a fix for this?
- Next by Date: Re: [RFC] [PATCH 1/8] inode_diet: Replace inode.u.generic_ip with inode.i_private
- Previous by thread: Re: [RFC] [PATCH 1/8] inode_diet: Replace inode.u.generic_ip with inode.i_private
- Next by thread: Re: [RFC] [PATCH 1/8] inode_diet: Replace inode.u.generic_ip with inode.i_private
- Index(es):
Relevant Pages
|
|
