Hello, Christoph. On Thu, Apr 28, 2011 at 09:11:20AM -0500, Christoph Lameter wrote: > Sporadic erratic behavior exists today since any thread can add an > abitrary number to its local counter while you are adding up all the per > cpu differentials. If this happens just after you picked up the value then > a single cpu can cause a high deviation. If multiple cpus do this then a > high degree of deviation can even be had with todays implementation. Yeah, but that's still something which is expected. If the user is adding/subtracing large number concurrently, sure. What I'm concerned about is adding unexpected deviation. Currently, the _sum interface basically provides basically the same level of expectedness (is this even a word?) as atomic_t - the deviations are solely caused and limited by concurrent updates. After the proposed changes, one concurrent updater doing +1 can cause @batch deviation. > Can you show in some tests how the chance of deviations is increased? If > at all then in some special sitations. Maybe others get better? It's kinda obvious, isn't it? Do relatively low freq (say, every 10ms) +1's and continuously do _sum(). Before, _sum() would never deviate much from the real count. After, there will be @batch jumps. If you still need proof code, I would write it but please note that I'm pretty backed up. > The counters were always designed to be racy for performance reasons. > Trying to serialize them goes against the design of these things. In order > to increase accuracy you have to decrease the allowable delta in the per > cpu differentials. > > Looping over all differentials to get more accuracy is something that may > not work as we have seen recently with the VM counters issues that caused > bad behavior during reclaim. Such users then shouldn't use _sum() - maybe rename it to _very_slow_sum() if you're concerned about misusage. percpu_counter() is already used in filesystems to count free blocks and there are times where atomic_t type accuracy is needed and _sum() achieves that. The proposed changes break that. Why do I need to say this over and over again? Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>