Hi Pavan, On 5/8/20 2:06 PM, Pavan Kondeti wrote: > On Thu, May 07, 2020 at 07:07:22PM +0530, Parth Shah wrote: >> Restrict the call to deeper idle states when the given CPU has been set for >> the least latency requirements >> >> Signed-off-by: Parth Shah <pa...@linux.ibm.com> >> --- >> kernel/sched/idle.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c >> index b743bf38f08f..85d72a6e2521 100644 >> --- a/kernel/sched/idle.c >> +++ b/kernel/sched/idle.c >> @@ -262,7 +262,8 @@ static void do_idle(void) >> * broadcast device expired for us, we don't want to go deep >> * idle as we know that the IPI is going to arrive right away. >> */ >> - if (cpu_idle_force_poll || tick_check_broadcast_expired()) { >> + if (cpu_idle_force_poll || tick_check_broadcast_expired() || >> + per_cpu(nr_lat_sensitive, cpu)) { >> tick_nohz_idle_restart_tick(); >> cpu_idle_poll(); >> } else { >> -- >> 2.17.2 >> > > Since nr_lat_sensitive updates can happen remotely (when a latency sensitive > task becomes non-latency sensitive task), we may need to add this condition > in cpu_idle_poll() as well. >
Right. but if the CPU is running idle_task then it will again come back to do_idle and read the refcount. Its a penalty in power-saving for 1 do_idle() loop but it is difficult to put up checks for any change in latency_nice value. Thanks, Parth