All of lore.kernel.org
 help / color / mirror / Atom feed
From: Preeti U Murthy <preeti@linux.vnet.ibm.com>
To: Alex Shi <alex.shi@intel.com>
Cc: Paul Turner <pjt@google.com>,
	Michael Wang <wangyun@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Borislav Petkov <bp@alien8.de>,
	Namhyung Kim <namhyung@kernel.org>,
	Mike Galbraith <efault@gmx.de>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	LKML <linux-kernel@vger.kernel.org>, Mel Gorman <mgorman@suse.de>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH v5 7/7] sched: consider runnable load average in effective_load
Date: Mon, 06 May 2013 15:29:20 +0530	[thread overview]
Message-ID: <51877EF8.20504@linux.vnet.ibm.com> (raw)
In-Reply-To: <51877970.8010303@intel.com>

On 05/06/2013 03:05 PM, Alex Shi wrote:
> On 05/06/2013 05:06 PM, Paul Turner wrote:
>> I don't think this is a good idea:
>>
>> The problem with not using the instantaneous weight here is that you
>> potentially penalize the latency of interactive tasks (similarly,
>> potentially important background threads -- e.g. garbage collection).
>>
>> Counter-intuitively we actually want such tasks on the least loaded
>> cpus to minimize their latency.  If the load they contribute ever
>> becomes more substantial we trust that periodic balance will start
>> taking notice of them.
> 
> Sounds reasonable. Many thanks for your input, Paul!
> 
> So, will use the seconds try. :)
>>
>> [ This is similar to why we have to use the instantaneous weight in
>> calc_cfs_shares. ]
>>
> 
> 

Yes thank you very much for the inputs Paul :)

So Alex, Michael looks like this is what happened.

1. The effective_load() as it is, uses instantaneous loads to calculate
the CPU shares before and after a new task can be woken up on the given cpu.

2. With my patch, I modified it to use runnable load average while
calculating the CPU share *after* a new task could be woken up and
retained instantaneous load to calculate the CPU share before a new task
could be woken up.

3. With the first patch of Alex, he has used runnable load average while
calculating the CPU share both before and after a new task could be
woken up on the given CPU.

4.The suggestions that Alex gave:

Suggestion1: Would change the CPU share calculation to use runnable load
average all the time.

Suggestion2: Did opposite of point 2 above,it used runnable load average
while calculating the CPU share *before* a new task has been woken up
while it retaining the instantaneous weight to calculate the CPU share
after a new task could be woken up.

So since there was no uniformity in the calculation of CPU shares in
approaches 2 and 3, I think it caused a regression. However I still
don't understand how approach 4-Suggestion2 made that go away although
there was non-uniformity in the CPU shares calculation.

But as Paul says we could retain the usage of instantaneous loads
wherever there is calculation of CPU shares for the reason he mentioned
and leave effective_load() and calc_cfs_shares() untouched.

This also brings forth another question,should we modify wake_affine()
to pass the runnable load average of the waking up task to effective_load().

What do you think?


Thanks

Regards
Preeti U Murthy


  reply	other threads:[~2013-05-06 11:15 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-06  1:45 [PATCH v5 0/7] use runnable load avg in load balance Alex Shi
2013-05-06  1:45 ` [PATCH v5 1/7] Revert "sched: Introduce temporary FAIR_GROUP_SCHED dependency for load-tracking" Alex Shi
2013-05-06  8:24   ` Paul Turner
2013-05-06  8:49     ` Alex Shi
2013-05-06  8:55       ` Paul Turner
2013-05-06  8:58         ` Alex Shi
2013-05-07  5:05         ` Alex Shi
2013-05-06  1:45 ` [PATCH v5 2/7] sched: remove SMP cover for runnable variables in cfs_rq Alex Shi
2013-05-06  4:11   ` Preeti U Murthy
2013-05-06  7:18     ` Alex Shi
2013-05-06  8:01   ` Paul Turner
2013-05-06  8:57     ` Alex Shi
2013-05-06  9:08       ` Paul Turner
2013-05-06 10:47         ` Preeti U Murthy
2013-05-06 15:02         ` Alex Shi
2013-05-07  5:07         ` Alex Shi
2013-05-06  1:45 ` [PATCH v5 3/7] sched: set initial value of runnable avg for new forked task Alex Shi
2013-05-06  8:19   ` Paul Turner
2013-05-06  9:21     ` Alex Shi
2013-05-06 10:17       ` Paul Turner
2013-05-07  2:18         ` Alex Shi
2013-05-07  3:06           ` Paul Turner
2013-05-07  3:24             ` Alex Shi
2013-05-07  5:03               ` Alex Shi
2013-05-09  8:31                 ` Alex Shi
2013-05-09  9:30                   ` Paul Turner
2013-05-09 14:23                     ` Alex Shi
2013-05-08 11:15               ` Peter Zijlstra
2013-05-09  9:34               ` Paul Turner
2013-05-07  9:57             ` Morten Rasmussen
2013-05-07 11:05               ` Alex Shi
2013-05-07 11:20                 ` Paul Turner
2013-05-08 11:34                   ` Peter Zijlstra
2013-05-08 12:00                     ` Paul Turner
2013-05-09 10:55                       ` Morten Rasmussen
2013-05-09  8:22                     ` Alex Shi
2013-05-09  9:24                       ` Paul Turner
2013-05-09 13:13                         ` Alex Shi
2013-05-06 10:22       ` Paul Turner
2013-05-06 15:26         ` Alex Shi
2013-05-06 15:28           ` Peter Zijlstra
2013-05-07  2:19   ` Alex Shi
2013-05-06  1:45 ` [PATCH v5 4/7] sched: update cpu load after task_tick Alex Shi
2013-05-06  1:45 ` [PATCH v5 5/7] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task Alex Shi
2013-05-06  8:46   ` Paul Turner
2013-05-06 10:19     ` Peter Zijlstra
2013-05-06 10:33       ` Paul Turner
2013-05-06 11:10         ` Peter Zijlstra
2013-05-07  6:17           ` Alex Shi
2013-06-04  1:45             ` Alex Shi
2013-06-04  1:51               ` [DISCUSSION] removing variety rq->cpu_load ? Alex Shi
2013-06-04  2:33                 ` Michael Wang
2013-06-04  2:44                   ` Alex Shi
2013-06-04  3:09                     ` Michael Wang
2013-06-04  4:55                       ` Alex Shi
2013-05-06 15:00     ` [PATCH v5 5/7] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task Alex Shi
2013-05-06 18:34       ` Paul Turner
2013-05-07  0:24         ` Alex Shi
2013-05-07  5:12         ` Alex Shi
2013-05-06  1:45 ` [PATCH v5 6/7] sched: consider runnable load average in move_tasks Alex Shi
2013-05-06  8:53   ` Paul Turner
2013-05-06 15:04     ` Peter Zijlstra
2013-05-06 20:59       ` Paul Turner
2013-05-07  5:17         ` Alex Shi
2013-05-08  1:39           ` Alex Shi
2013-05-09  1:24             ` Alex Shi
2013-05-10 13:58               ` Alex Shi
2013-05-09  5:29             ` Alex Shi
2013-05-10 14:03               ` Alex Shi
2013-05-06 15:07     ` Alex Shi
2013-05-06  1:45 ` [PATCH v5 7/7] sched: consider runnable load average in effective_load Alex Shi
2013-05-06  3:34   ` Michael Wang
2013-05-06  5:39     ` Alex Shi
2013-05-06  6:11       ` Michael Wang
2013-05-06  9:39         ` Alex Shi
2013-05-06  7:49       ` Michael Wang
2013-05-06  8:02         ` Alex Shi
2013-05-06  8:34           ` Michael Wang
2013-05-06  9:06             ` Paul Turner
2013-05-06  9:35               ` Alex Shi
2013-05-06  9:59                 ` Preeti U Murthy [this message]
2013-05-07  2:43                   ` Michael Wang
2013-05-07  5:43                   ` Alex Shi
2013-05-08  1:33                     ` Alex Shi
2013-05-06 10:00                 ` Paul Turner
2013-05-06  7:10     ` Preeti U Murthy
2013-05-06  7:20       ` Michael Wang

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=51877EF8.20504@linux.vnet.ibm.com \
    --to=preeti@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@intel.com \
    --cc=bp@alien8.de \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=riel@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=wangyun@linux.vnet.ibm.com \
    /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.