Messages in this thread | | | Date | Fri, 14 Jul 2017 09:03:14 -0700 | From | Andi Kleen <> | Subject | Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods |
| |
On Fri, Jul 14, 2017 at 05:58:53PM +0200, Peter Zijlstra wrote: > On Fri, Jul 14, 2017 at 08:52:28AM -0700, Arjan van de Ven wrote: > > On 7/14/2017 8:38 AM, Peter Zijlstra wrote: > > > No, that's wrong. We want to fix the normal C state selection process to > > > pick the right C state. > > > > > > The fast-idle criteria could cut off a whole bunch of available C > > > states. We need to understand why our current C state pick is wrong and > > > amend the algorithm to do better. Not just bolt something on the side. > > > > I can see a fast path through selection if you know the upper bound of any > > selection is just 1 state.
fast idle doesn't have an upper bound.
If the prediction exceeds the fast idle threshold any C state can be used.
It's just another state (fast C1), but right now it has an own threshold which may be different from standard C1.
> > > > But also, how much of this is about "C1 be fast" versus "selecting C1 is slow" > > I got the impression its about we need to select C1 for longer. But the > fact that the patches don't in fact answer any of these questions, > they're wrong in principle ;-)
For that workload. Tuning idle thresholds is a complex trade off.
-Andi
| |