Messages in this thread | | | Subject | Re: [patch V3] percpu_counter: scalability works | From | Eric Dumazet <> | Date | Tue, 17 May 2011 14:20:07 +0200 |
| |
Le mardi 17 mai 2011 à 11:50 +0200, Tejun Heo a écrit :
> 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. >
Spikes are expected and have no effect by design.
batch value is chosen so that granularity of the percpu_counter (batch*num_online_cpus()) is the spike factor, and thats pretty difficult when number of cpus is high.
In Shaohua workload, 'amount' for a 128Mbyte mapping is 32768, while the batch value is 48. 48*24 = 1152. So the percpu s32 being in [-47 .. 47] range would not change the accuracy of the _sum() function [ if it was eventually called, but its not ]
No drift in the counter is the only thing we care - and _read() being not too far away from the _sum() value, in particular if the percpu_counter is used to check a limit that happens to be low (against granularity of the percpu_counter : batch*num_online_cpus()).
I claim extra care is not needed. This might give the false impression to reader/user that percpu_counter object can replace a plain atomic64_t.
For example, I feel vm_committed_as could be a plain atomic_long_t
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |