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.
