All of lore.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>,
	Juri Lelli <juri.lelli@arm.com>
Subject: Re: [PATCH 4/4] sched/fair: Implement flat hierarchical structure for util_avg
Date: Thu, 14 Apr 2016 02:20:25 +0800	[thread overview]
Message-ID: <20160413182025.GN8697@intel.com> (raw)
In-Reply-To: <CAKfTPtDVRy=RCJaLBa2_KVx2tk3SsuUPDhDLcovf+kpT-artbQ@mail.gmail.com>

Hi Vincent,

On Wed, Apr 13, 2016 at 01:27:21PM +0200, Vincent Guittot wrote:
> >> Why not using the sched_avg of the rq->cfs in order to track the
> >> utilization of the root cfs_rq instead of adding a new sched_avg into
> >> the rq ? Then you call update_cfs_rq_load_avg(rq->cfs) when you want
> >> to update/sync the utilization of the rq->cfs and for one call you
> >> will update both the load_avg and the util_avg of the root cfs instead
> >> of duplicating the sequence in _update_load_avg
> >
> > This is the approach taken by Dietmar in his patch, a fairly easy approach.
> > The problem is though, if so, we update the root cfs_rq only when it is
> > the root cfs_rq to update. A simple contrived case will make it never
> > updated except in update_blocked_averages(). My impression is that this
> > might be too much precision lost.
> >
> > And thus we take this alternative approach, and thus I revisited
> > __update_load_avg() to optimize it.
> >
> > [snip]
> >
> >> > -       if (atomic_long_read(&cfs_rq->removed_util_avg)) {
> >> > -               long r = atomic_long_xchg(&cfs_rq->removed_util_avg, 0);
> >> > -               sa->util_avg = max_t(long, sa->util_avg - r, 0);
> >> > -               sa->util_sum = max_t(s32, sa->util_sum - r * LOAD_AVG_MAX, 0);
> >> > +       if (atomic_long_read(&rq->removed_util_avg)) {
> >> > +               long r = atomic_long_xchg(&rq->removed_util_avg, 0);
> >> > +               rq->avg.util_avg = max_t(long, rq->avg.util_avg - r, 0);
> >> > +               rq->avg.util_sum = max_t(s32, rq->avg.util_sum - r * LOAD_AVG_MAX, 0);
> >>
> >> I see one potential issue here because the rq->util_avg may (surely)
> >> have been already updated and decayed during the update of a
> >> sched_entity but before we substract the removed_util_avg
> >
> > This is the same now, because cfs_rq will be regularly updated in
> > update_blocked_averages(), which basically means cfs_rq will be newer
> > than task for sure, although task tries to catch up when removed.
> 
> I don't agree on that part. At now, we check and substract
> removed_util_avg before calling __update_load_avg for a cfs_rq, so it
> will be removed before changing last_update_time.

Despite the cross CPU issue, you are right.

> With your patch,  we update rq->avg.util_avg and last_update_time
> without checking removed_util_avg.

But, yes, we do.

      reply	other threads:[~2016-04-14  2:02 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-10 22:36 [PATCH 0/4] Optimize sched avg computation and implement flat util hierarchy Yuyang Du
2016-04-10 22:36 ` [PATCH 1/4] sched/fair: Optimize sum computation with a lookup table Yuyang Du
2016-04-11  9:08   ` Vincent Guittot
2016-04-11 10:41   ` Juri Lelli
2016-04-11 19:12     ` Yuyang Du
2016-04-12 10:14       ` Juri Lelli
2016-04-12 18:07         ` Yuyang Du
2016-04-13  9:11           ` Juri Lelli
2016-04-11 16:59   ` Dietmar Eggemann
2016-04-11 19:17     ` Yuyang Du
2016-04-12 14:19       ` Peter Zijlstra
2016-04-12 18:12         ` Yuyang Du
2016-04-11 23:21     ` Joe Perches
2016-04-12 12:02       ` Juri Lelli
2016-04-11 23:07   ` Joe Perches
2016-04-10 22:36 ` [PATCH 2/4] sched/fair: Drop out incomplete current period when sched averages accrue Yuyang Du
2016-04-11  9:08   ` Vincent Guittot
2016-04-11 19:41     ` Yuyang Du
2016-04-12 11:56       ` Vincent Guittot
2016-04-12 21:09         ` Yuyang Du
2016-04-13 11:11           ` Vincent Guittot
2016-04-12 12:02   ` Dietmar Eggemann
2016-04-12 20:14     ` Yuyang Du
2016-04-13  4:04       ` Joe Perches
2016-04-13  8:40       ` Morten Rasmussen
2016-04-13 15:13   ` Dietmar Eggemann
2016-04-13 15:28     ` Vincent Guittot
2016-04-13 16:20       ` Vincent Guittot
2016-04-13 18:44       ` Yuyang Du
2016-04-14 12:52         ` Dietmar Eggemann
2016-04-14 20:05           ` Yuyang Du
2016-04-18 17:59             ` Yuyang Du
2016-04-10 22:36 ` [PATCH 3/4] sched/fair: Modify accumulated sums for load/util averages Yuyang Du
2016-04-11 17:14   ` Dietmar Eggemann
2016-04-10 22:36 ` [PATCH 4/4] sched/fair: Implement flat hierarchical structure for util_avg Yuyang Du
2016-04-11 12:29   ` Vincent Guittot
2016-04-11 20:37     ` Yuyang Du
2016-04-13 11:27       ` Vincent Guittot
2016-04-13 18:20         ` 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=20160413182025.GN8697@intel.com \
    --to=yuyang.du@intel.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=morten.rasmussen@arm.com \
    --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 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.