[lkml]   [2006]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Slimming down struct inode
On Sat, Jun 10, 2006 at 02:27:57AM +0100, Al Viro wrote:
> > 5) Nuke i_cindex. This is only used by ieee1394's
> > ieee_file_to_instance. There must be another place where we can
> > store this --- say, in a ieee1394-specific field in struct file? Or
> > maybe it can be derived some other way, but to chew up 4 bytes in
> > i_cindex for all inodes just for ieee1394's benefit seems like the
> > Wrong Thing(tm).
> No, it's actually the right thing for _all_ char devices. And it's used
> before we get a struct file. If anything, ->i_rdev should go long-term...

i_cindex is set by fs/char_dev.h, and the only user of that field (I
grepped the entire sources) is ./drivers/ieee1394/ieee1394_core.h:

/* return the index (within a minor number block) of a file */
static inline unsigned char ieee1394_file_to_instance(struct file *file)
return file->f_dentry->d_inode->i_cindex;

> > 6) Separate out those elements which are only used if the inode is open
> > into a separate data structure (call it "struct inode_state" for
> > the sake of argument):
> >
> > i_flock, i_mapping, i_data, i_dnotify_mask, i_dnotify,
> > inotify_watches, inotify_sem, i_state, dirtied_when,
> > i_size_seqcount, i_mutex, i_alloc_sem
> >
> It is not safe e.g. for ->i_mutex, since that puppy is used not only when
> there's an opened file over this inode (or, in fact, before any method
> had been called for this inode).
> It is _certainly_ not safe for ->i_state (take a look at fs/inode.c).
> It is not safe for ->i_data, unless you are willing to dispose of page
> cache on close (even leaving aside such things as directories).
> No comments on idiotify fields - IIRC, they can also be used before any
> ->open() on the inode in question.

You're right, I added some fields which can't be moved out of struct
inode, but the basic point remains; it should be possible to shrink
struct inode by moving fields to an inode_state structure.

As far as i/dnotify fields are concerned, yes, they can be used on an
unopened inode, but we could also simply consider a file that is being
watched by i/dnotify as one that is "opened" from the point of view of
needing a inode_state structure to be allocated. Depending on how
many files a typical GUI desktop is going to watch, this might or
might not be good idea.


- Ted
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-06-10 03:59    [W:0.104 / U:7.688 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site