From: Preeti U Murthy <preeti@linux.vnet.ibm.com>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, Mike Galbraith <efault@gmx.de>,
Paul Turner <pjt@google.com>, Alex Shi <alex.shi@intel.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Namhyung Kim <namhyung@kernel.org>
Subject: Re: [PATCH v2 3/3] sched: clean-up struct sd_lb_stat
Date: Tue, 06 Aug 2013 14:52:19 +0530 [thread overview]
Message-ID: <5200C04B.8030507@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130805073248.GC27240@lge.com>
Hi Joonsoo,
On 08/05/2013 01:02 PM, Joonsoo Kim wrote:
>>> + if (busiest->group_imb) {
>>> + busiest->sum_weighted_load =
>>> + min(busiest->sum_weighted_load, sds->sd_avg_load);
>>
>> Right here we get confused as to why the total load is being compared
>> against load per task (although you are changing it to load per task above).
>
> Yes, you are right. I will add load_per_task to struct sg_lb_stats.
>
>
>>> @@ -4771,12 +4763,13 @@ static inline void calculate_imbalance(struct lb_env *env, struct sd_lb_stats *s
>>> * Be careful of negative numbers as they'll appear as very large values
>>> * with unsigned longs.
>>> */
>>> - max_pull = min(sds->max_load - sds->avg_load, load_above_capacity);
>>> + max_pull = min(busiest->avg_load - sds->sd_avg_load,
>>> + load_above_capacity);
>>
>> This is ok, but readability wise max_load is much better. max_load
>> signifies the maximum load per task on a group in this sd, and avg_load
>> signifies the total load per task across the sd. You are checking if
>> there is imbalance in the total load in the sd and try to even it out
>> across the sd. Here "busiest" does not convey this immediately.
>
> You may be confused. max_load doesn't means the maximum load per task.
> It means that the busiest group's load per cpu power. And here max doesn't
> mean maximum load in this sd, instead, load of busiest sg. IMO,
> busiest->avg_load convey proper meaning.
Yes sorry about that. It is load per cpu power. My point was that
max_load helped in readability. Look at the these two lines in your patch.
- max_pull = min(sds->max_load - sds->avg_load, load_above_capacity);
+ max_pull = min(busiest->avg_load - sds->sd_avg_load,
>>> + load_above_capacity);
The deleted line says that there is an imbalance in the load/cpu in some
part of the sd(max_load), which is above the average load of the sd, which
we are trying to even out. Something like the below diagram for the sd load.
max_load
_/\________ avg_load.
I believe the line you have added makes it hard to understand this.
Anyway this is a minor issue, you can ignore it.
Regards
Preeti U Murthy
prev parent reply other threads:[~2013-08-06 9:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-02 1:50 [PATCH v2 0/3] optimization, clean-up about fair.c Joonsoo Kim
2013-08-02 1:50 ` [PATCH v2 1/3] sched: remove one division operation in find_buiest_queue() Joonsoo Kim
2013-08-02 1:50 ` [PATCH v2 2/3] sched: factor out code to should_we_balance() Joonsoo Kim
2013-08-02 4:22 ` Preeti U Murthy
2013-08-02 9:05 ` 김준수
2013-08-02 9:26 ` Preeti U Murthy
2013-08-02 10:32 ` Peter Zijlstra
2013-08-05 4:22 ` Preeti U Murthy
2013-08-05 7:21 ` Joonsoo Kim
2013-08-02 10:20 ` Peter Zijlstra
2013-08-05 7:22 ` Joonsoo Kim
2013-08-02 7:51 ` Vincent Guittot
2013-08-02 9:08 ` Joonsoo Kim
2013-08-02 1:50 ` [PATCH v2 3/3] sched: clean-up struct sd_lb_stat Joonsoo Kim
2013-08-02 4:40 ` Preeti U Murthy
2013-08-05 7:32 ` Joonsoo Kim
2013-08-06 9:22 ` Preeti U Murthy [this message]
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=5200C04B.8030507@linux.vnet.ibm.com \
--to=preeti@linux.vnet.ibm.com \
--cc=alex.shi@intel.com \
--cc=efault@gmx.de \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=pjt@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox