linux-kernel - Re: [PATCH] Percpu tag allocator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20130613120439.fe56d178a1143089136fdacc@linux-foundation.org>
Date:	Thu, 13 Jun 2013 12:04:39 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	Kent Overstreet <koverstreet@...gle.com>,
	linux-kernel@...r.kernel.org, Oleg Nesterov <oleg@...hat.com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	Andi Kleen <andi@...stfloor.org>, Jens Axboe <axboe@...nel.dk>,
	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	Jeff Layton <jlayton@...hat.com>,
	"J. Bruce Fields" <bfields@...ldses.org>
Subject: Re: [PATCH] Percpu tag allocator

On Thu, 13 Jun 2013 11:53:18 -0700 Tejun Heo <tj@...nel.org> wrote:

> Hello, Andrew, Kent.
> 
> (cc'ing NFS folks for id[r|a] discussion)
> 
> On Wed, Jun 12, 2013 at 08:03:11PM -0700, Andrew Morton wrote:
> > They all sound like pretty crappy reasons ;) If the idr/ida interface
> > is nasty then it can be wrapped to provide the same interface as the
> > percpu tag allocator.
> > 
> > I could understand performance being an issue, but diligence demands
> > that we test that, or at least provide a convincing argument.
> 
> The thing is that id[r|a] guarantee that the lowest available slot is
> allocated

That isn't the case for ida_get_new_above() - the caller gets to
control the starting index.

> and this is important because it's used to name things which
> are visible to userland - things like block device minor number,
> device indicies and so on.  That alone pretty much ensures that
> alloc/free paths can't be very scalable which usually is fine for most
> id[r|a] use cases as long as lookup is fast.  I'm doubtful that it's a
> good idea to push per-cpu tag allocation into id[r|a].  The use cases
> are quite different.

You aren't thinking right.

The worst outcome here is that idr.c remains unimproved and we merge a
new allocator which does basically the same thing.

The best outcome is that idr.c gets improved and we don't have to merge
duplicative code.

So please, let's put aside the shiny new thing for now and work out how
we can use the existing tag allocator for these applications.  If we
make a genuine effort to do this and decide that it's fundamentally
hopeless then this is the time to start looking at new implementations.

(I can think of at least two ways of making ida_get_new_above() an
order of magnitude faster for this application and I'm sure you guys
can as well.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/