From: Preeti U Murthy <preeti@linux.vnet.ibm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: "peterz@infradead.org" <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>, Rik van Riel <riel@redhat.com>,
Morten Rasmussen <Morten.Rasmussen@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
Mike Galbraith <efault@gmx.de>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
"daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Subject: Re: [QUERY] Confusing usage of rq->nr_running in load balancing
Date: Wed, 10 Sep 2014 13:51:05 +0530 [thread overview]
Message-ID: <541009F1.1070906@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAKfTPtDYXeCnYgR0yU2Ed-XBP9ezfk-j1gCgEyiReyQjD5hC6Q@mail.gmail.com>
On 09/05/2014 05:57 PM, Vincent Guittot wrote:
> On 5 September 2014 14:19, Preeti U Murthy <preeti@linux.vnet.ibm.com> wrote:
>> Hi Vincent,
>>
>> On 09/03/2014 10:28 PM, Vincent Guittot wrote:
>>> On 3 September 2014 14:21, Preeti U Murthy <preeti@linux.vnet.ibm.com> wrote:
>>>> Hi,
>>>
>>> Hi Preeti,
>>>
>>>>
>>>> There are places in kernel/sched/fair.c in the load balancing part where
>>>> rq->nr_running is used as against cfs_rq->nr_running. At least I could
>>>> not make out why the former was used in the following scenarios.
>>>> It looks to me that it can very well lead to incorrect load balancing.
>>>> Also I did not pay attention to the numa balancing part of the code
>>>> while skimming through this file to catch this scenario. There are a
>>>> couple of places there too which need to be scrutinized.
>>>>
>>>> 1. load_balance(): The check (busiest->nr_running > 1)
>>>> The load balancing would be futile if there are tasks of other
>>>> scheduling classes, wouldn't it?
>>>
>>> agree with you
>>>
>>>>
>>>> 2. active_load_balance_cpu_stop(): A similar check and a similar
>>>> consequence as 1 here.
>>>
>>> agree with you
>>>
>>>>
>>>> 3. nohz_kick_needed() : We check for more than one task on the runqueue
>>>> and hence trigger load balancing even if there are rt-tasks.
>>>
>>> I can see one potentiel reason why rq->nr_running is interesting that
>>> is the group capacity might have changed because of non cfs tasks
>>> since last load balance. So we need to monitor the change of the
>>> groups' capacity to ensure that the average load of each group is
>>> still in the same level
>>>
>>>>
>>>> 4. cpu_avg_load_per_task(): This stands out among the rest as an
>>>> incorrect usage of rq->nr_running in place of cfs_rq->nr_running. We
>>>> divide the load associated with the cfs_rq by the number of tasks on the
>>>> rq. This will make the cfs_rq load look smaller.
>>>
>>> This one is solved in the consolidation of cpu_capacity patchset
>>
>> Sorry, but I don't see where in your patchset you have addressed this
>> issue. Can you please point out the patch?
>
> In [PATCH v5 03/12] sched: fix avg_load computation:
>
> static unsigned long cpu_avg_load_per_task(int cpu)
> {
> struct rq *rq = cpu_rq(cpu);
> - unsigned long nr_running = ACCESS_ONCE(rq->nr_running);
> + unsigned long nr_running = ACCESS_ONCE(rq->cfs.h_nr_running);
> unsigned long load_avg = rq->cfs.runnable_load_avg;
>
> Are you referring to another problem than the one above ?
No Vincent, this is one. Thanks for pointing it out.
Regards
Preeti U Murthy
>
> Regards
> Vincent
>
>>
>> Regards
>> Preeti U Murthy
>>
>
next prev parent reply other threads:[~2014-09-10 8:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-03 12:21 [QUERY] Confusing usage of rq->nr_running in load balancing Preeti U Murthy
2014-09-03 15:30 ` Peter Zijlstra
2014-09-03 16:58 ` Vincent Guittot
2014-09-05 12:19 ` Preeti U Murthy
2014-09-05 12:27 ` Vincent Guittot
2014-09-10 8:21 ` Preeti U Murthy [this message]
2014-09-15 4:16 ` Preeti U Murthy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=541009F1.1070906@linux.vnet.ibm.com \
--to=preeti@linux.vnet.ibm.com \
--cc=Morten.Rasmussen@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=dietmar.eggemann@arm.com \
--cc=efault@gmx.de \
--cc=kamalesh@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=srikar@linux.vnet.ibm.com \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.