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

[Tejun Heo]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/