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 15:10:40 -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 12:35:14 -0700 Tejun Heo <tj@...nel.org> wrote:

> > > Maybe we can layer things so that we have percpu layer on top of
> > > id[r|a] and, say, mapping id to point is still done by idr, or the
> > > percpu tag allocator uses ida for tag chunk allocations, but it's
> > > still gonna be something extra on top.
> > 
> > It's not obvious that explicit per-cpu is needed.  Get an ID from
> > ida_get_new_above(), multiply it by 16 and store that in device-local
> > storage, along with a 16-bit bitmap.  Blam, 30 lines of code and the
> > ida_get_new_above() cost is reduced 16x and it's off the map.
> 
> I'm fairly sure it'd have to be per-cpu.  The idr allocation is
> reduced 16x but now each of those 16 slots needs to be allocated.  The
> problem hasn't gone away and we do need some sort of utility to help
> that as drivers tend to resort to things like linear bitmap scan
> combined with test_and_set_bit() making one cacheline extremely hot.

Well OK, make it per-cpu then.  Or think up something better.

Look, we're falling into the age-old trap of trying to justify existing
code just because it exists.

Stop.  Take a step back and pretend that the percpu tag allocator patch
never existed.  Now, define the problem and propose solutions.

The absolute dead last and worst solution is "implement something new
which largely duplicates existing code".  Such a step requires an
extraordinary amount of justification and that hasn't happened.
--
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/