Messages in this thread | | | Subject | Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration | From | Alex Shi <> | Date | Mon, 23 Jan 2017 22:58:28 +0800 |
| |
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... :)
| |