Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration

[Alex Shi]

On 01/23/2017 08:50 PM, Daniel Lezcano wrote:
> On Sun, Jan 22, 2017 at 09:31:44AM +0800, Alex Shi wrote:
>>
>>> Yeah, that could be problematic. The code snippet gives the general idea but it
>>> could be changed by for example by a flag telling the cpus when they enter idle
>>> to update their state_count. Or something like that.
>>
>> Yes, this idea could be helpful.
>>
>> But since the idle path isn't a hot path. and a few memory access won't cost
>> a lot. So I doubt if the benefit could be measurable.
> 
> It won't be measurable, as well as reading the cpu device latency before
> checking the latency req is zero, but it makes sense.

Just simple change the cpu state may make it looks unnatural. :)
> 
> The idle routine is not a hot path but a very special place where the interrupt
> are disabled, the rcu is not usable, tick is disabled etc ...
> 
> Perhaps it is not a problem for the moment, but it is probably worth to mention that
> using API from other subsystems in the idle select path could be problematic
> and perhaps it is time to think about another approach for the future.
> 

Yes, before idle, it did consider lots of parts, included pm qos for
long time... :)