From: Mike Galbraith <efault@gmx.de>
To: Joel Fernandes <joelaf@google.com>, linux-kernel@vger.kernel.org
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@arm.com>,
Brendan Jackman <brendan.jackman@arm.com>,
Dietmar Eggeman <dietmar.eggemann@arm.com>,
kernel-team@android.com, Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH v2] sched/fair: Make PELT signal more accurate
Date: Sat, 19 Aug 2017 06:57:54 +0200 [thread overview]
Message-ID: <1503118674.5112.20.camel@gmx.de> (raw)
In-Reply-To: <20170818235026.618-1-joelaf@google.com>
On Fri, 2017-08-18 at 16:50 -0700, Joel Fernandes wrote:
> The PELT signal (sa->load_avg and sa->util_avg) are not updated if the amount
> accumulated during a single update doesn't cross a period boundary. This is
> fine in cases where the amount accrued is much smaller than the size of a
> single PELT window (1ms) however if the amount accrued is high then the
> relative error (calculated against what the actual signal would be had we
> updated the averages) can be high - as much 2% in my testing. On plotting
> signals, I found that there are errors especially high when we update just
> before the period boundary is hit. These errors can be significantly reduced if
> we update the averages more often.
>
> Inorder to fix this, this patch does the average update by also checking how
> much time has elapsed since the last update and update the averages if it has
> been long enough (as a threshold I chose 512us).
Ok, I gotta ask: In order to fix what? What exactly does the small
but existent overhead increase buy us other than an ever so slightly
different chart? What is your motivation to care about a microscopic
change in signal shape?
-Mike
next prev parent reply other threads:[~2017-08-19 4:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-18 23:50 [PATCH v2] sched/fair: Make PELT signal more accurate Joel Fernandes
2017-08-19 4:57 ` Mike Galbraith [this message]
2017-08-19 17:58 ` Joel Fernandes
2017-08-20 6:00 ` Mike Galbraith
2017-08-20 6:46 ` Joel Fernandes
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=1503118674.5112.20.camel@gmx.de \
--to=efault@gmx.de \
--cc=brendan.jackman@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=joelaf@google.com \
--cc=juri.lelli@arm.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.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.