linux-kernel - Re: [RFC 3/4] sched/idle: Disable idle call on least latency requirements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <328de1bf-57d1-023d-29aa-11a540212015@linux.ibm.com>
Date:   Fri, 8 May 2020 16:49:04 +0530
From:   Parth Shah <parth@...ux.ibm.com>
To:     Pavan Kondeti <pkondeti@...eaurora.org>
Cc:     linux-kernel@...r.kernel.org, peterz@...radead.org,
        mingo@...hat.com, vincent.guittot@...aro.org,
        dietmar.eggemann@....com, qais.yousef@....com,
        chris.hyser@...cle.com, valentin.schneider@....com,
        rjw@...ysocki.net
Subject: Re: [RFC 3/4] sched/idle: Disable idle call on least latency
 requirements

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 <parth@...ux.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