[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKfTPtC+AEy64jBjkTap0yYBiCt06gUb5FAtDyRtMPXy_-qQNw@mail.gmail.com>
Date: Mon, 12 Feb 2018 12:02:49 +0100
From: Vincent Guittot <vincent.guittot@...aro.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...nel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Valentin Schneider <valentin.schneider@....com>,
Morten Rasmussen <morten.rasmussen@...s.arm.com>,
Brendan Jackman <brendan.jackman@....com>,
Dietmar Eggemann <dietmar.eggemann@....com>
Subject: Re: [PATCH v3 1/3] sched: Stop nohz stats when decayed
On 12 February 2018 at 11:45, Peter Zijlstra <peterz@...radead.org> wrote:
> On Mon, Feb 12, 2018 at 09:07:52AM +0100, Vincent Guittot wrote:
>> @@ -9383,11 +9450,16 @@ static bool nohz_idle_balance(struct rq *this_rq, enum cpu_idle_type idle)
>> * work being done for other cpus. Next load
>> * balancing owner will pick it up.
>> */
>> - if (need_resched())
>> - break;
>> + if (need_resched()) {
>> + has_blocked_load = true;
>> + goto abort;
>> + }
>>
>> rq = cpu_rq(balance_cpu);
>>
>> + update_blocked_averages(rq->cpu);
>
> Does that want to be update_nohz_stats() ?
I was about to say yesy but the test if (!time_after(jiffies,
rq->last_blocked_load_update_tick)) worry me a bit because it can skip
the update and the chance to clear nohz.has_blocked.
As an example the tick is 10ms long on arm 32bits so we can easily
reach the 32ms decay within the current tick even if we have already
updated it
>
>> + has_blocked_load |= rq->has_blocked_load;
>> +
>> /*
>> * If time for next balance is due,
>> * do the balance.
Powered by blists - more mailing lists