On Fri, Apr 29, 2011 at 04:19:31PM +0800, Shaohua Li wrote: > > 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. > > ok, I got your point. I'd agree there is sporadic erratic behaviors, but > I expect there is no problem here. We all agree the worst case is the > same before/after the change. Any program should be able to handle the > worst case, otherwise the program itself is buggy. Discussing a buggy > program is meaningless. After the change, something behavior is changed, > but the worst case isn't. So I don't think this is a big problem. If you really think that, go ahead and remove _sum(), really. If you still can't see the difference between "reasonably accurate unless there's concurrent high frequency update" and "can jump on whatever", I can't help you. Worst case is important to consider but that's not the only criterion you base your decisions on. Think about it. It becomes the difference between "oh yeah, while my crazy concurrent FS benchmark is running, free block count is an estimate but otherwise it's pretty accruate" and "holy shit, it jumped while there's almost nothing going on the filesystem". It drastically limits both the usefulness of _sum() and thus the percpu counter and how much we can scale @batch on heavily loaded counters because it ends up directly affecting the accuracy of _sum(). 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>