Messages in this thread | | | Date | Mon, 28 Jan 2013 09:48:58 -0800 | From | Kent Overstreet <> | Subject | Re: [PATCH 23/32] Generic dynamic per cpu refcounting |
| |
On Thu, Jan 24, 2013 at 06:09:43PM -0800, Tejun Heo wrote: > Hello, again. > > On Thu, Jan 24, 2013 at 06:03:40PM -0800, Tejun Heo wrote: > > Yeah, if we're aiming to replace refcnts in file and kobj, dynamic > > alloc may be justified. Hopefully, the accounting necessary to decide > > whethre to use percpu isn't too burdensome. > > 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.
> Also, while kobj destruction can still be considered an infrequent > operation, file destruction is not and people will get mighty unhappy > if you do synchronize_sched/rcu() from fput() synchronously. > > 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.
But I really liked your idea for making dynamic allocation use a pool that's refilled from a workqueue, then I can keep dynamic allocation without contorting the api.
| |