Messages in this thread | | | Date | Thu, 9 Feb 2012 15:58:45 -0800 | From | Tejun Heo <> | Subject | Re: [PATCHSET] block, mempool, percpu: implement percpu mempool and fix blkcg percpu alloc deadlock |
| |
Hello, guys.
On Wed, Jan 04, 2012 at 05:28:42PM -0800, Tejun Heo wrote: > On Tue, Dec 27, 2011 at 04:41:02PM -0800, Tejun Heo wrote: > > Hello, > > > > On Wed, Dec 28, 2011 at 09:14:02AM +0900, KAMEZAWA Hiroyuki wrote: > > > > This is essentially more specialized form of the mempool approach. It > > > > doesn't seem any simpler to me while being less generic. I don't see > > > > what the upside would be. > > > > > > Hm, but this never causes -ENOMEM error, at all. > > > > Ooh, I missed the part it falls back to the global counter if percpu > > counters aren't allocated yet. Yeah, this is an interesting approach. > > I'll think more about it. > > I've been staring at the blkcg stats code and commit logs and am > wondering whether we can just scrap percpu counters there. It seems > the reason why it was introduced in the first place is to avoid > stats->lock, which BTW is extremely heavy handed for gathering stats, > overhead in fast paths and I think there can be easier ways to avoid > stats->lock.
I could remove stats_lock without much trouble but couldn't get blk-throtl fast path stat working. :(
I think I'll try to get KAMEZAWA's percpu counter working. Any objections?
Thanks.
-- tejun
| |