On 08/16, Frederic Weisbecker wrote: > > On Fri, Aug 16, 2013 at 06:49:22PM +0200, Oleg Nesterov wrote: > > > > Personally I am fine either way. > > Me too. > > So my proposition is that we can keep the existing patches as they fix other > distinct races
perhaps... but it would be nice to fix the "goes backward" problem. This "race" is not theoretical, at least for get_cpu_iowait_time_us(). nr_iowait_cpu() can change from !0 to 0 very easily. And just in case, note that get_cpu_idle_time_us() has the same problem too, because it can also change from 0 to !0 although this case is much less likely. However, right now I do not see a simple solution. It seems that, if get_cpu_idle_time_us() does ktime_add(ts->idle_sleeptime) it should actually update ts->idle_sleeptime/entrytime to avoid these races (the same for ->idle_sleeptime), but then we need the locking. > (and we add fixes on what peterz just reported) Do you mean his comments about 4/4 or I missed something else? > Ah and I'll wait for > your review first. If only I could understand this code ;) It looks really simple and I hope I can understand what it does. But not why. I simply can't understand why idle/iowait are "mutually exclusive". And if we do this, then perhaps io_schedule() should do "if (atomic_dec(&rq->nr_iowait)) update_iowait_sleeptime()" but this means the locking again. > Then if all goes well on the pull request we describe him the nr_iowait race > and we let him > choose what to do with that nr_iowait migration race: OK, agreed. > Or may be Peter could tell us as well. Peter, do you have a preference? Yes, it would be nice to know what Peter thinks ;) Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
