Messages in this thread | | | Date | Tue, 18 Jul 2017 09:24:24 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods |
| |
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?
I did, but that data is no proof that it is unfixable. It's just data describing the current situation, not more not less.
> There are some unavoidable slow operations in the current path -- e.g.
That's the whole point: current path, IOW current implementation.
This implementation is not set in stone and we rather fix it than just creating a side channel and leave everything else as is.
Thanks,
tglx
| |