On Sun, Jul 20, 2014 at 04:47:59AM -0700, Paul E. McKenney wrote: > On Sat, Jul 19, 2014 at 08:01:24PM +0200, Frederic Weisbecker wrote: > > On Sat, Jul 19, 2014 at 09:53:50AM -0700, Paul E. McKenney wrote: > > > If a non-nohz_full= CPU is non-idle, it will have a scheduling-clock > > > interrupt, and therefore doesn't need the timekeeping CPU to keep > > > its scheduling-clock interrupt going. This commit therefore ignores > > > the idle state of non-nohz_full CPUs when determining whether or not > > > the timekeeping CPU can safely turn off its scheduling-clock interrupt. > > > > > > Signed-off-by: Paul E. McKenney <[email protected]> > > > > Unfortunately that's not how things work. Running a CPU tick doesn't > > necessarily > > imply to run the timekeeping duty. > > > > Only the timekeeper can update the timekeeping. There is an exception > > though: > > the timekeeping is also updated by dynticks idle CPUs when they wake up in > > an > > interrupt from idle. > > > > Here is in practice why it doesn't work: > > > > So lets say CPU 0 is timekeeper, CPU 1 a non-nohz-full CPU and all others > > are full-nohz. > > CPU 0 is sleeping. CPU 1 wakes up from idle, so it has an uptodate > > timekeeping but then > > if it continues to execute further without waking up CPU 0, it risks stale > > timestamps. > > > > This can be changed by allowing timekeeping duty from all non-nohz_full > > CPUs, that's > > the initial direction I took, but it involved a lot of complications and > > scalability > > issues. > > So we really have to have -all- the CPUs be idle to turn off the timekeeper. > This won't make the battery-powered embedded guys happy...
I can imagine all sorts of solutions to solve this. None of them look simple though. And I'm really convinced this isn't worth until some user comes up and report me that 1) he seriously uses full dynticks and 2) he needs non-full-nohz CPUs other than CPU 0. If 1 and 2 ever happen, I'll gladly work on this. > > Other thoughts on this? We really should not be setting > CONFIG_NO_HZ_FULL_SYSIDLE by default until this is solved. Well it's better to save energy when all CPUs are idle than never. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
