On Wed, Sep 29, 2010 at 10:07:59PM -0400, Christoph Hellwig wrote: > 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. Sounds like a good plan, but I don't really have time right now to understand the iget routines of every single filesystem to determine which rely on the current new_inode() allocated inode number. I think that is best left for a later cleanup, seeing as the last_ino scalability problem is easily addressed.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
