On Wed, 2011-04-27 at 18:20 +0800, Tejun Heo wrote: > Hello, Shaohua. > > On Wed, Apr 27, 2011 at 01:43:29PM +0800, Shaohua Li wrote: > > > That would be a pathelogical case but, even then, after the change the > > > number becomes much higher as it becomes a function of batch * > > > num_updaters, right? > > > > I don't understand the difference between batch * num_updaters and batch > > * num_cpus except preempt. So the only problem here is _add should have > > preempt disabled? I agree preempt can make deviation worse. > > except the preempt issue, are there other concerns against the atomic > > convert? in the preempt disabled case, before/after the atomic convert > > the deviation is the same (batch*num_cpus) > > Yes, with preemption disabled, I think the patheological worst case > wouldn't be too different. > > > > I don't really worry about _sum performance. It's a quite slow path > > > and most of the cost is from causing cacheline bounces anyway. That > > > said, I don't see how the above would help the deviation problem. > > > Let's say an updater reset per cpu counter but got preempted before > > > updating the global counter. What differences does it make to check > > > fbc->counter before & after like above? > > > > yes, this is a problem. Again I don't mind to disable preempt in _add. > > Okay, this communication failure isn't my fault. Please re-read what > I wrote before, my concern wasn't primarily about pathological worst > case - if that many concurrent updates are happening && the counter > needs to be accurate, it can't even use atomic counter. It should be > doing full exclusion around the counter and the associated operation > _together_. > > I'm worried about sporadic erratic behavior happening regardless of > update frequency and preemption would contribute but isn't necessary > for that to happen. Ok, I misunderstood the mail you sent to Christoph, sorry. So you have no problem about the atomic convert. I'll update the patch against base tree, given the preemptless patch has problem. Thanks, Shaohua -- 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>