Messages in this thread | | | Subject | Re: [patch V3] percpu_counter: scalability works | From | Shaohua Li <> | Date | Wed, 18 May 2011 09:00:43 +0800 |
| |
On Tue, 2011-05-17 at 17:50 +0800, Tejun Heo wrote: > Hello, Eric. > > On Tue, May 17, 2011 at 11:45:41AM +0200, Eric Dumazet wrote: > > _sum() is a bit more precise than percpu_counter_read(), but to make it > > really precise, we means we have to stop concurrent activities, and we > > never did in previous/current implementation. > > > > We could add this (as Shaohua and myself tried in various patches) > > later, if needed, but nowhere in kernel we currently need that. > > > > Even /proc/meminfo doesnt call _sum(&vm_committed_as) but the lazy > > percpu_counter_read_positive() function... > > > > Reammy _sum() gives a good approximation of the counter, more precise > > because of the percpu s32 folding, but no guarantee of deviation. > > I'm not asking to make it more accurate but the initial patches from > Shaohua made the _sum() result to deviate by @batch even when only one > thread is doing _inc() due to the race window between adding to the > main counter and resetting the local one. All I'm asking is closing > that hole and I'll be completely happy with it. The lglock does that > but it's ummm.... not a very nice way to do it. > > Please forget about deviations from concurrent activities. I don't > care and nobody should. All I'm asking is removing that any update > having the possibility of that unnecessary spike and I don't think > that would be too hard. Hmm, we once again to talk about the deviation issue. I thought we agreed the deviation issue should be resolved in last discussion, but seems not...
I would suggest you guys seriously look at my v3 patches, which doesn't use lglock but can solve the deviation issue and has no significant overhead.
Thanks, Shaohua
| |