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 2/4] sched/fair: Drop out incomplete current period when sched averages accrue
Date: Tue, 12 Apr 2016 03:41:41 +0800 [thread overview]
Message-ID: <20160411194141.GH8697@intel.com> (raw)
In-Reply-To: <CAKfTPtDP4uUWevKFjjYiqyAyVPaFrLmtn11wSRMpYD60O2Jc=w@mail.gmail.com>
Hi Vincent,
On Mon, Apr 11, 2016 at 11:08:04AM +0200, Vincent Guittot wrote:
> > @@ -2704,11 +2694,14 @@ static __always_inline int
> > __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
> > unsigned long weight, int running, struct cfs_rq *cfs_rq)
> > {
> > - u64 delta, scaled_delta, periods;
> > - u32 contrib;
> > - unsigned int delta_w, scaled_delta_w, decayed = 0;
> > + u64 delta;
> > + u32 contrib, periods;
> > unsigned long scale_freq, scale_cpu;
> >
> > + /*
> > + * now rolls down to a period boundary
> > + */
> > + now = now && (u64)(~0xFFFFF);
> > delta = now - sa->last_update_time;
> > /*
> > * This should only happen when time goes backwards, which it
> > @@ -2720,89 +2713,56 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
> > }
> >
> > /*
> > - * Use 1024ns as the unit of measurement since it's a reasonable
> > - * approximation of 1us and fast to compute.
> > + * Use 1024*1024ns as an approximation of 1ms period, pretty close.
> > */
> > - delta >>= 10;
> > - if (!delta)
> > + periods = delta >> 20;
> > + if (!periods)
> > return 0;
> > sa->last_update_time = now;
>
> The optimization looks quite interesting but I see one potential issue
> with migration as we will lose the part of the ongoing period that is
> now not saved anymore. This lost part can be quite significant for a
> short task that ping pongs between CPUs.
Yes, basically, it is we lose precision (~1ms scale in contrast with ~1us scale).
But as I wrote, we may either lose a sub-1ms, or gain a sub-1ms, statistically,
they should even out, given the load/util updates are quite a large number of
samples, and we do want a lot of samples for the metrics, this is the point of
the entire average thing. Plus, as you also said, the incomplete current period
also plays a (somewhat) negative role here.
In addition, excluding the flat hierarchical util patch, we gain quite some
efficiency.
next prev parent reply other threads:[~2016-04-12 3:24 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 [this message]
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
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=20160411194141.GH8697@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.