From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH 15/18] fs: introduce a per-cpu last_ino allocator Date: Fri, 08 Oct 2010 16:06:12 +0200 Message-ID: <1286546772.2959.372.camel@edumazet-laptop> References: <1286515292-15882-1-git-send-email-david@fromorbit.com> <1286515292-15882-16-git-send-email-david@fromorbit.com> <20101008095658.GA19804@ZenIV.linux.org.uk> <20101008100346.GA27737@infradead.org> <1286533219.2959.128.camel@edumazet-laptop> <20101008134821.GA15157@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Al Viro , Dave Chinner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Christoph Hellwig Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:48825 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753429Ab0JHOGR (ORCPT ); Fri, 8 Oct 2010 10:06:17 -0400 In-Reply-To: <20101008134821.GA15157@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Le vendredi 08 octobre 2010 =C3=A0 09:48 -0400, Christoph Hellwig a =C3= =A9crit : > 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 hav= e > > hard guarantee two sockets on machine dont have same inum. > >=20 > > A reasonable compromise here is to use a simple and scalable alloca= tor, > > and take the risk two sockets have same inum. > >=20 > > While it might break some applications playing fstats() games, on > > sockets, current schem is vastly faster. > >=20 > > I worked with machines with millions of opened socket concurrently, > > iunique() was not an option, and application didnt care of possible= inum > > clash. >=20 > 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. >=20 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-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html