On Mon, 17 Jul 2017, Andi Kleen wrote:
> On Tue, Jul 18, 2017 at 08:43:53AM +0200, Thomas Gleixner wrote:
> > On Mon, 17 Jul 2017, Andi Kleen wrote:
> >
> > > > We need a tradeoff here IMHO. I'll check Daniel's work to understand
> > > > how/if
> > > > it's better than menu governor.
> > >
> > > I still would like to see how the fast path without the C1 heuristic
> > > works.
> > >
> > > Fast pathing is a different concept from a better predictor. IMHO we need
> > > both, but the first is likely lower hanging fruit.
> >
> > Hacking something on the side is always the lower hanging fruit as it
> > avoids solving the hard problems. As Peter said already, that's not going
> > to happen unless there is a real technical reason why the general path
> > cannot be fixed. So far there is no proof for that.
>
> You didn't look at Aubrey's data?
>
> There are some unavoidable slow operations in the current path -- e.g.
> reprograming the timer for NOHZ. But we don't need that for really
> short idle periods, because as you pointed out they never get woken
> up by the tick.
>
> Similar for other things like RCU.
>
> I don't see how you can avoid that other than without a fast path mechanism.
You can very well avoid it by taking the irq timings or whatever other
information into account for the NOHZ decision.
Thanks,
tglx
