linux-kernel - Re: [PATCH 23/32] Generic dynamic per cpu refcounting

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:	Mon, 28 Jan 2013 10:18:39 -0800
From:	Tejun Heo <tj@...nel.org>
To:	Kent Overstreet <koverstreet@...gle.com>
Cc:	linux-kernel@...r.kernel.org, linux-aio@...ck.org,
	linux-fsdevel@...r.kernel.org, zab@...hat.com, bcrl@...ck.org,
	jmoyer@...hat.com, axboe@...nel.dk, viro@...iv.linux.org.uk,
	tytso@....edu, Oleg Nesterov <oleg@...hat.com>,
	srivatsa.bhat@...ux.vnet.ibm.com, Christoph Lameter <cl@...ux.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH 23/32] Generic dynamic per cpu refcounting

Hello, Kent.

On Mon, Jan 28, 2013 at 09:48:58AM -0800, Kent Overstreet wrote:
> > Ooh, I forgot one thing.  We might not gain much by replacing file
> > refcnt w/ this.  You can't really get cheaper than fget_light().
> 
> I've seen fget() show up when profiling the aio code - it's not high
> enough to be a big concern when not doing stupid stuff, but high enough
> that making it percpu would be worth it if it was easy. Which it's not,
> for plenty of reasons.

Yeah, aio wouldn't be able to use fget_light().

> > So, I'm now back to "do we need dynamic allocation".  What else do we
> > have to convert?
> 
> I dunno. There's a lot of random refcounts scattered around, though.
> 
> The way I see it, if it's always percpu when joe random dev needs a
> refcount, he's going to weigh whether the overhead of a percpu refcount
> is worth it.
> 
> With dynamic allocation, it's 16 bytes if you don't need it to be
> percpu, vs. 4 for an atomic_t - so you never need to think about it, you
> can just always use this for your refcounts and never have to think
> about if it's going to be a fast path thing or not.

Yes, that is an appealing thought and it would actually improve
something unlike kref silliness.  One concern is that when not
converted to percpu, there will be overhead for extra bookkeeping.  It
probably can be offset by flipping to percpu mode earlier.  Anyways,
it would be great if both the percpu and non-percpu fast paths light.

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/