public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


      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