On Wed, Sep 29, 2010 at 10:18:47PM +1000, Dave Chinner wrote: > From: Eric Dumazet <dada1@xxxxxxxxxxxxx> > > last_ino was converted to an atomic variable to allow the inode_lock > to go away. However, contended atomics do not scale on large > machines, and new_inode() triggers excessive contention in such > situations. And the good thing is most users of new_inode couldn't care less about the fake i_ino assigned because they have a real inode number. So the first step is to move the i_ino assignment into a separate helper and only use it in those filesystems that need it. Second step is to figure out why some filesystems need iunique() and some are fine with the incrementing counter and then we should find a scalable way to generate an inode number - preferably just one and not to, but if that's not possible we need some documentation on why which one is needed. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
