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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
