linux-kernel - Re: [PATCH v2 1/2] sched: force update of blocked load of idle cpus

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] [day] [month] [year] [list]

Date:   Thu, 21 Dec 2017 11:01:15 +0100
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Brendan Jackman <brendan.jackman@....com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Ingo Molnar <mingo@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Morten Rasmussen <morten.rasmussen@....com>
Subject: Re: [PATCH v2 1/2] sched: force update of blocked load of idle cpus

On 20 December 2017 at 15:27, Vincent Guittot
<vincent.guittot@...aro.org> wrote:
> On 20 December 2017 at 15:09, Peter Zijlstra <peterz@...radead.org> wrote:
>> On Fri, Dec 01, 2017 at 06:01:56PM +0000, Brendan Jackman wrote:
>>
>>> @@ -9210,7 +9256,15 @@ static void nohz_idle_balance(struct rq *this_rq, enum cpu_idle_type idle)
>>>                       cpu_load_update_idle(rq);
>>>                       rq_unlock_irq(rq, &rf);
>>>
>>> -                     rebalance_domains(rq, CPU_IDLE);
>>> +                     update_blocked_averages(balance_cpu);
>>> +                     /*
>>> +                      * This idle load balance softirq may have been
>>> +                      * triggered only to update the blocked load and shares
>>> +                      * of idle CPUs (which we have just done for
>>> +                      * balance_cpu). In that case skip the actual balance.
>>> +                      */
>>> +                     if (!in_nohz_stats_kick(this_cpu))
>>> +                             rebalance_domains(rq, idle);
>>>               }
>>>
>>>               if (time_after(next_balance, rq->next_balance)) {
>>
>>> @@ -9336,7 +9396,12 @@ static __latent_entropy void run_rebalance_domains(struct softirq_action *h)
>>>        * and abort nohz_idle_balance altogether if we pull some load.
>>>        */
>>>       nohz_idle_balance(this_rq, idle);
>>> -     rebalance_domains(this_rq, idle);
>>> +     update_blocked_averages(this_rq->cpu);
>>> +     if (!in_nohz_stats_kick(this_rq->cpu))
>>> +             rebalance_domains(this_rq, idle);
>>> +#ifdef CONFIG_NO_HZ_COMMON
>>> +     clear_bit(NOHZ_STATS_KICK, nohz_flags(this_rq->cpu));
>>> +#endif
>>>  }
>>>
>>>  /*
>>
>> You're doing the same thing to both (all) callsites of
>> rebalance_domains(), does that not suggest doing it inside and leaving
>> update_blocked_averages() where it is?
>
> The goal of moving update_blocked_averages() outside rebalance_domains
> is to not add a new parameter or use a special  cpu_idle_type value in
> rebalance_domains parameters in order to abort the rebalance sequence
> just after updating blocked load

Peter,
Is the reason above reasonable or you prefer update_blocked_averages
to stay in rebalance_domains ?

>
>>
>>