[lkml]   [2001]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux/Pro -- clusters
    Daniel Phillips wrote:
    > On December 4, 2001 04:19 pm, Jeff Garzik wrote:
    > > ug. what's wrong with a single additional alloc for generic_ip? [if a
    > > filesystem needs to do multiple allocs post-conversion, somebody's doing
    > > something wrong]
    > Single additional alloc -> twice as many allocs, two slabs, more cachelines
    > dirty. This was hashed out on fsdevel, though apparently not to everyone's
    > satisfaction.
    > > Using generic_ip in its current form has the advantage of being able to
    > > create a nicely-aligned kmem cache for your private inode data.
    > I don't see why that's hard with the combined struct.

    The advantage of having two structs means that both struct inode and the
    private info can be aligned nicely. Yes it potentially wastes a tiny
    bit more memory, but I challenge you to find an architecture where doing
    this isn't a win. In a couple cases I looked at, additional slabs are
    not even necessary, as kmalloc's standard ones do the job quite well.
    'cat /proc/slabinfo' for a list of the sizes.

    Note this only applies to inodes. There aren't enough superblocks in a
    running system to worry about doing anything but simple kmalloc on the
    superblock private info (before assigning to generic_sbp).


    Jeff Garzik | Only so many songs can be sung
    Building 1024 | with two lips, two lungs, and one tongue.
    MandrakeSoft | - nomeansno

    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: 2005-03-22 13:13    [W:0.024 / U:2.240 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site