Re: [PATCH 15/18] fs: introduce a per-cpu last_ino allocator

[Eric Dumazet]

Le vendredi 08 octobre 2010 Ã 09:48 -0400, Christoph Hellwig a Ãcrit :
> On Fri, Oct 08, 2010 at 12:20:19PM +0200, Eric Dumazet wrote:
> > If iunique() was scalable, sockets could use it, so that we can have
> > hard guarantee two sockets on machine dont have same inum.
> > 
> > A reasonable compromise here is to use a simple and scalable allocator,
> > and take the risk two sockets have same inum.
> > 
> > While it might break some applications playing fstats() games, on
> > sockets, current schem is vastly faster.
> > 
> > I worked with machines with millions of opened socket concurrently,
> > iunique() was not an option, and application didnt care of possible inum
> > clash.
> 
> The current version of iuniqueue is indeed rather suboptimal.  As is
> the pure counter approach.  I think the right way to deal with it
> is to use an idr allocator.  This means the filesystem needs to
> explicitly free the inode number when the inode is gone, but that
> just makes the usage more clear.  Together with the lazy assignment
> scheme for synthetic filesystems that should give us both speed and
> correctness.
> 

On 32bit arches, inum for sockets/pipes could be pretty fast

unsigned u32 rnd_val __read_mostly; /* seeded at boot time */

unsigned u32 get_inum(struct inode *ino, size_t size)
{
	return rnd_val ^ ((long)ino + random32() % size);
}

(Ie , use fact that an inode is a kernel object, with a given address
and a given size, two inodes cannot overlap)


I have no idea how scalable is an idr allocator, but it probably uses
one big lock.

Maybe finally generate 64bit inum on 64bit arches...



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/