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]

Date:	Thu, 13 Jun 2013 11:53:18 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Andrew Morton <akpm@...ux-foundation.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

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

In fact, maybe what we can do is adding some features on top of the
tag allocator and moving id[r|a] users which don't require strict
in-order allocation to it.  For example, NFS allocates an ID for each
transaction it performs and uses it to index the associate command
structure (Jeff, Bruce, please correct me if I'm getting it wrong).
The only requirement on IDs is that they shouldn't be recycled too
fast.  Currently, idr implements cyclic mode for it but it can easily
be replaced with per-cpu tag allocator like this one and it'd be a lot
more scalable.  There are a couple things to worry about tho - it
probably should use the highbits as generation number as a tag is
given out so that the actual ID doesn't get recycled quickly, and some
form dynamic tag sizing would be nice too.

Thanks.

-- 
tejun
--
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/