lkml.org 
[lkml]   [2001]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: hundreds of mount --bind mountpoints?
    From
    On Mon, Apr 23, 2001 at 10:45:05PM +0200, Ingo Oeser wrote:
    > Last time we suggested this, people ended up with some OS trying
    > it and getting worse performance.
    >
    > Why? You need to allocate the VFS-inode (vnode in other OSs) and
    > the on-disk-inode anyway at the same time. You get better
    > performance and less fragmentation, if you allocate them both
    > together[1].
    >
    > So that struct inode around is ok.
    >
    > BTW: Is it still less than one page? Then it doesn't make me
    > nervous. Why? Guess what granularity we allocate at, if we
    > just store pointers instead of the inode.u. Or do you like
    > every FS creating his own slab cache?

    I've actually got the coda_inode_info (inode->u.u_coda_fs_i) split out
    of the union in my development kernel. It doesn't shrink the size of the
    struct inode yet, Coda isn't the biggest user at the moment.

    But, it forced me to do several cleanups in the code, and it even has
    resulted in fixing a 'leak'. Not a real memory loss leak one, but we
    left uninitialized inodes around in the icache for no good reason. Also
    changing a but in a coda specific header file does trigger an almost
    complete rebuild of the whole kernel (coda.h -> coda_fs_i.h -> fs.h ->
    everything?)

    The allocation overhead really isn't that bad. kmalloc/kfree are also
    using the slabcache, and a trivial variant using a 'private' slabcache
    gave me the counters to find the 'leak' I mentioned before.

    I can't really evaluate performance impacts. The struct inode is still
    the same size, so for now there even is a little bit of additional
    memory pressure. Also, Coda wasn't really developed to achieve high
    performance but more to explore novel features.

    Jan

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:27    [W:0.028 / U:30.136 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site