On Thu, 28 Apr 2011, Tejun Heo wrote: > Hmm... we're now more lost than ever. :-( Can you please re-read my > message two replies ago? The one where I talked about sporadic > erratic behaviors in length and why I was worried about it. > > In your last reply, you talked about preemption and that you didn't > have problems with disabling preemption, which, unfortunately, doesn't > have much to do with my concern with the sporadic erratic behaviors > and that's what I pointed out in my previous reply. So, it doesn't > feel like anything is resolved. 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. 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? 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. -- 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>