On Thu, 21 Apr 2011, Tejun Heo wrote: > > The interregnum is very short and since the counters are already fuzzy > > this is tolerable. We do the same thing elsewhere for vmstats. > > We're talking about three different levels of fuzziness. > > 1. percpu_counter_sum() before the changes > > May deviate by the number of concurrent updaters and cacheline > update latencies. Not true. Any of the updaters may have done multiple updates by the time we are through cycling through the list. > 2. percpu_counter_sum() after the changes > > May deviate by multiples of @batch; however, the duration > during which the deviation may be visible is brief (really? > we're allowing preemption between local and global updates). Well again there is general fuzziness here and we are trying to make the best of it without compromising performance too much. Shaohua's numbers indicate that removing the lock is very advantagous. More over we do the same thing in other places. > So, unless someone can show me that percpu_counter_sum() is > unnecessary (ie. the differences between not only #1 and #2 but also > between #1 and #3 are irrelevant), I don't think I'm gonna change the > slow path. It's silly to micro optimize slow path to begin with and > I'm not gonna do that at the cost of subtle functionality change which > can bite us in the ass in twisted ways. Actually its good to make the code paths for vmstats and percpu counters similar. That is what this does too. Preempt enable/disable in any function that is supposedly fast is something bad that can be avoided with these patches as well. -- 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>