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

Eric Dumazet
2010-10-08T14:06:18Z

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