All of lore.kernel.org
 help / color / mirror / Atom feed
From: Morten Rasmussen <morten.rasmussen@arm.com>
To: Leo Yan <leo.yan@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Steve Muckle <steve.muckle@linaro.org>,
	linux-kernel@vger.kernel.org, eas-dev@lists.linaro.org
Subject: Re: [PATCH RFC] sched/fair: let cpu's cfs_rq to reflect task migration
Date: Mon, 4 Apr 2016 10:01:08 +0100	[thread overview]
Message-ID: <20160404090108.GB18516@e105550-lin.cambridge.arm.com> (raw)
In-Reply-To: <1459528717-17339-1-git-send-email-leo.yan@linaro.org>

On Sat, Apr 02, 2016 at 12:38:37AM +0800, Leo Yan wrote:
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 0fe30e6..10ca1a9 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2825,12 +2825,24 @@ static inline u64 cfs_rq_clock_task(struct cfs_rq *cfs_rq);
>  static inline int update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
>  {
>  	struct sched_avg *sa = &cfs_rq->avg;
> +	struct sched_avg *cpu_sa = NULL;
>  	int decayed, removed = 0;
> +	int cpu = cpu_of(rq_of(cfs_rq));
> +
> +	if (&cpu_rq(cpu)->cfs != cfs_rq)
> +		cpu_sa = &cpu_rq(cpu)->cfs.avg;
>  
>  	if (atomic_long_read(&cfs_rq->removed_load_avg)) {
>  		s64 r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0);
>  		sa->load_avg = max_t(long, sa->load_avg - r, 0);
>  		sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0);
> +
> +		if (cpu_sa) {
> +			cpu_sa->load_avg = max_t(long, cpu_sa->load_avg - r, 0);
> +			cpu_sa->load_sum = max_t(s64,
> +					cpu_sa->load_sum - r * LOAD_AVG_MAX, 0);

I think this is not quite right. 'r' is the load contribution removed
from a group cfs_rq. Unless the task is the only task in the group and
the group shares are default, this value is different from the load
contribution of the task at root level (task_h_load()).

And how about nested groups? I think you may end up removing the
contribution of a task multiple times from the root cfs_rq if it is in a
nested group.

You will need to either redesign group scheduling so you get the load to
trickle down automatically and with the right contribution, or maintain
a new sum at the root bypassing the existing design. I'm not sure if the
latter makes sense for load though. It would make more sense for
utilization only.

> @@ -2919,6 +2939,13 @@ skip_aging:
>  	cfs_rq->avg.load_sum += se->avg.load_sum;
>  	cfs_rq->avg.util_avg += se->avg.util_avg;
>  	cfs_rq->avg.util_sum += se->avg.util_sum;
> +
> +	if (&cpu_rq(cpu)->cfs != cfs_rq) {
> +		cpu_rq(cpu)->cfs.avg.load_avg += se->avg.load_avg;
> +		cpu_rq(cpu)->cfs.avg.load_sum += se->avg.load_sum;
> +		cpu_rq(cpu)->cfs.avg.util_avg += se->avg.util_avg;
> +		cpu_rq(cpu)->cfs.avg.util_sum += se->avg.util_sum;
> +	}

Same problem as above. You should be adding the right amount of task
contribution here. Something similar to task_h_load(). The problem with
using task_h_load() is that it is not updated immediately either, so
maintaining a stable signal based on that might be difficult.

      parent reply	other threads:[~2016-04-04  8:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-01 16:38 [PATCH RFC] sched/fair: let cpu's cfs_rq to reflect task migration Leo Yan
2016-04-01 19:49 ` Peter Zijlstra
2016-04-01 22:28   ` Steve Muckle
2016-04-02  7:11     ` Leo Yan
2016-04-04  8:48       ` Morten Rasmussen
2016-04-04 18:30         ` Yuyang Du
2016-04-05  7:51           ` Morten Rasmussen
2016-04-05  0:15             ` Yuyang Du
2016-04-05 17:00               ` Dietmar Eggemann
2016-04-06  8:37                 ` Morten Rasmussen
2016-04-06 12:14                   ` Vincent Guittot
2016-04-06 18:53                   ` Dietmar Eggemann
2016-04-07 13:04                     ` Vincent Guittot
2016-04-07 20:30                       ` Dietmar Eggemann
2016-04-08  6:05                         ` Vincent Guittot
2016-04-05  6:56         ` Leo Yan
2016-04-05  9:13           ` Morten Rasmussen
2016-04-04  9:01 ` Morten Rasmussen [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=20160404090108.GB18516@e105550-lin.cambridge.arm.com \
    --to=morten.rasmussen@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=eas-dev@lists.linaro.org \
    --cc=leo.yan@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=steve.muckle@linaro.org \
    --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.