public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yuyang Du <yuyang.du@intel.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Benjamin Segall <bsegall@google.com>,
	Paul Turner <pjt@google.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	Mike Galbraith <umgwanakikbuti@gmail.com>
Subject: Re: [PATCH v1 00/10] Optimize sched avgs computation and implement flat util hierarchy
Date: Wed, 24 Aug 2016 03:01:12 +0800	[thread overview]
Message-ID: <20160823190112.GD3273@intel.com> (raw)
In-Reply-To: <CAKfTPtAMWbx6m2X8k_px+TK7OGAqgzD+0ShwfNb02xP1O8wg0Q@mail.gmail.com>

Hi Vincent,

On Tue, Aug 23, 2016 at 03:28:19PM +0200, Vincent Guittot wrote:
> I still wonder if using a flat util hierarchy is the right solution to
> solve this problem with utilization and task group. I have noticed
> exact same issues with load that generates weird task placement
> decision and i think that we should probably try to solve both wrong
> behavior with same mechanism. but this is not possible with flat
> hierarchy for load

I agree both util and load have the same hierarchical propagation
problem.

But util and load are different with respect to task group distribution
among CPUs and along hierarchical structure. Util is "fundamentally"
flat (CPU's util = tasks' util), so it's pretty natural as well as
simple to implement a flat hierarchy util. And because of that, I
feel util propagating up the hierarchical structure seems unnecessary.

It might be better to have a converged mechanism to solve both, but
it shouldn't be necessary. Right?

> Let me take an example.
> TA is a always running task on CPU1 in group /root/level1/
> TB wakes up on CPU0 and moves TA into group /root/level2/
> Even if TA stays on CPU1, runnable_load_avg of CPU1 root cfs rq will become 0.
> Then, TB forks a new task TC. TC will probably be schedule on CPU1
> because its root cfs_rq's runnable_load_avg is null and CPU1 is the
> next CPU after CPU0
> 
> Similar behavior can happen when TA migrates
> 
> Beside flat utilization consideration, i'm going to have a look at the

Many thanks.

Yuyang

      parent reply	other threads:[~2016-08-24  3:09 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-10  0:14 [PATCH v1 00/10] Optimize sched avgs computation and implement flat util hierarchy Yuyang Du
2016-08-10  0:14 ` [PATCH v1 01/10] sched/fair: Chance LOAD_AVG_MAX_N from 345 to 347 Yuyang Du
2016-08-24 16:01   ` Vincent Guittot
2016-08-29  0:07     ` Yuyang Du
2016-08-10  0:14 ` [PATCH v1 02/10] documentation: Add scheduler/sched-avg.txt Yuyang Du
2016-08-22 16:48   ` Randy Dunlap
2016-08-10  0:14 ` [PATCH v1 03/10] sched/fair: Add static to remove_entity_load_avg() Yuyang Du
2016-08-10  0:14 ` [PATCH v1 04/10] sched/fair: Rename variable names for sched averages Yuyang Du
2016-08-10  0:14 ` [PATCH v1 05/10] sched/fair: Add __always_inline compiler attribute to __accumulate_sum() Yuyang Du
2016-08-10  0:14 ` [PATCH v1 06/10] sched/fair: Optimize __update_sched_avg() Yuyang Du
2016-08-10  0:14 ` [PATCH v1 07/10] sched/fair: Remove useless 64-bit to 32-bit variable conversion Yuyang Du
2016-08-25  7:11   ` Vincent Guittot
2016-08-29  1:00     ` Yuyang Du
2016-08-10  0:14 ` [PATCH v1 08/10] sched/fair: Remove scale_load_down() for load_avg Yuyang Du
2016-08-10  0:14 ` [PATCH v1 09/10] sched/fair: Rename scale_load() and scale_load_down() Yuyang Du
2016-08-10  0:14 ` [PATCH v1 10/10] sched/fair: Implement flat hierarchical structure for util_avg Yuyang Du
2016-08-10  0:23 ` [PATCH v1 00/10] Optimize sched avgs computation and implement flat util hierarchy Yuyang Du
2016-08-22 23:26   ` Yuyang Du
2016-08-23 13:28     ` Vincent Guittot
2016-08-23 14:13       ` Peter Zijlstra
2016-08-23 14:45         ` Vincent Guittot
2016-08-23 15:39           ` Dietmar Eggemann
2016-08-29  1:37             ` Yuyang Du
2016-09-01 18:32               ` Dietmar Eggemann
2016-08-24  8:54           ` Morten Rasmussen
2016-08-24  9:48             ` Vincent Guittot
2016-08-29 19:00             ` Yuyang Du
2016-09-01 14:22               ` Morten Rasmussen
2016-08-23 19:09         ` Yuyang Du
2016-08-23 19:01       ` Yuyang Du [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=20160823190112.GD3273@intel.com \
    --to=yuyang.du@intel.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=umgwanakikbuti@gmail.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