From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kent Overstreet Subject: Re: [PATCH 23/32] Generic dynamic per cpu refcounting Date: Mon, 28 Jan 2013 09:48:58 -0800 Message-ID: <20130128174858.GW26407@google.com> References: <1356573611-18590-1-git-send-email-koverstreet@google.com> <1356573611-18590-26-git-send-email-koverstreet@google.com> <20130125005136.GE2373@mtj.dyndns.org> <20130125011345.GT26407@google.com> <20130125020340.GG2373@mtj.dyndns.org> <20130125020943.GH2373@mtj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-kernel@vger.kernel.org, linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, zab@redhat.com, bcrl@kvack.org, jmoyer@redhat.com, axboe@kernel.dk, viro@zeniv.linux.org.uk, tytso@mit.edu, Oleg Nesterov , srivatsa.bhat@linux.vnet.ibm.com, Christoph Lameter , "Paul E. McKenney" , Rusty Russell To: Tejun Heo Return-path: Content-Disposition: inline In-Reply-To: <20130125020943.GH2373@mtj.dyndns.org> Sender: owner-linux-aio@kvack.org List-Id: linux-fsdevel.vger.kernel.org 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, send a message with 'unsubscribe linux-aio' in the body to majordomo@kvack.org. For more info on Linux AIO, see: http://www.kvack.org/aio/ Don't email: aart@kvack.org