On Fri, Jul 14, 2017 at 11:56:33AM +0800, Li, Aubrey wrote:
> On 2017/7/14 2:28, Peter Zijlstra wrote:
> > On Thu, Jul 13, 2017 at 11:13:28PM +0800, Li, Aubrey wrote:
> >> On 2017/7/13 22:53, Peter Zijlstra wrote:
> >
> >>> Fixing C-state selection by creating an alternative idle path sounds so
> >>> very wrong.
> >>
> >> This only happens on the arch which has multiple hardware idle cstates,
> >> like
> >> Intel's processor. As long as we want to support multiple cstates, we have
> >> to
> >> make a selection(with cost of timestamp update and computation). That's
> >> fine
> >> in the normal idle path, but if we want a fast idle switch, we can make a
> >> tradeoff to use a low-latency one directly, that's why I proposed a fast
> >> idle
> >> path, so that we don't need to mix fast idle condition judgement in both
> >> idle
> >> entry and idle exit path.
> >
> > That doesn't make sense. If you can decide to pick a shallow C state in
> > any way, you can fix the general selection too.
> >
>
> Okay, maybe something like the following make sense? Give a hint to
> cpuidle_idle_call() to indicate a fast idle.
>
> --------------------------------------------------------
> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> index ef63adc..3165e99 100644
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -152,7 +152,7 @@ static void cpuidle_idle_call(void)
> */
> rcu_idle_enter();
>
> - if (cpuidle_not_available(drv, dev)) {
> + if (cpuidle_not_available(drv, dev) || this_is_a_fast_idle) {
> default_idle_call();
> goto exit_idle;
> }
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.
