On Thu, 28 Apr 2011, Tejun Heo wrote: > It seems like we can split hairs all day long about the similarities > and differences with atomics, so let's forget about atomics for now. Ok good idea. So you accept that per cpu counters are inevitably fuzzy and that the result cannot be relied upon in the same way as on atomics? > I don't like any update having possibility of causing @batch jumps in > _sum() result. That severely limits the usefulness of hugely > expensive _sum() and the ability to scale @batch. Not everything in > the world is vmstat. Think about other _CURRENT_ use cases in > filesystems. Of course you can cause jumps > batch. You are looping over 8 cpus and have done cpu 1 and 2 already. Then cpu 1 adds batch-1 to the local per cpu counter. cpu 2 increments its per cpu counter. When _sum returns we have deviation of batch. In the worst case the deviation can increase to (NR_CPUS - 1) * (batch -1). That is for the current code!!! The hugely expensive _sum() is IMHO pretty useless given the above. It is a function that is called with the *hope* of getting a more accurate result. The only way to reduce the fuzziness is by reducing batch. But then you dont need the _sum function. Either that or you need additional external synchronization by the subsystem that prevents updates. -- 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>