[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.022 / U:128.064 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site