On Thu, Mar 30, 2017 at 09:58:44AM +0800, Wanpeng Li wrote: > 2017-03-30 4:08 GMT+08:00 Rik van Riel <r...@redhat.com>: > > > > In other words, the tick on cpu0 is aligned > > with the tick on the nohz_full cpus, and > > jiffies is advanced while the nohz_full cpus > > with an active tick happen to be in kernel > > mode? > > > > Frederic, can you think of any reason why > > the tick on nohz_full CPUs would end up aligned > > with the tick on cpu0, instead of running at some > > random offset? > > > > A random offset, or better yet a somewhat randomized > > tick length to make sure that simultaneous ticks are > > fairly rare and the vtime sampling does not end up > > "in phase" with the jiffies incrementing, could make > > the accounting work right again. > > > > Of course, that assumes the above hypothesis is correct :) > > There is such a feature skew_tick currently, refer to commit > 5307c9556bc (tick: add tick skew boot option), w/ skew_tick=1 boot > parameter, the bug disappear, however, the commit also mentioned that > it will hurt power consumption.
Oh, I completely missed that! > I will try Frederic's proposal which > is similar to my original idea "how bad would it be to revert to > sched_clock() instead of jiffies in vtime_delta()? We could use > nanosecond granularity to check deltas but only perform an actual > cputime update when that delta >= TICK_NSEC." Thanks! I hope sched_clock() won't introduce too much overhead. Otherwise we may want to pick up the skew_tick solution.