From: David Woodhouse <dwmw2@infradead.org>
To: Suleiman Souhlal <suleiman@google.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
joelaf@google.com, vineethrp@google.com,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
ssouhlal@freebsd.org
Subject: Re: [PATCH] sched: Don't try to catch up excess steal time.
Date: Tue, 20 Aug 2024 16:50:53 +0100 [thread overview]
Message-ID: <185314eedbe4e19a2a1cd7faf32b9a3a3e6acd07.camel@infradead.org> (raw)
In-Reply-To: <20240806111157.1336532-1-suleiman@google.com>
[-- Attachment #1: Type: text/plain, Size: 2952 bytes --]
On Tue, 2024-08-06 at 20:11 +0900, Suleiman Souhlal wrote:
> When steal time exceeds the measured delta when updating clock_task, we
> currently try to catch up the excess in future updates.
> However, this results in inaccurate run times for the future clock_task
> measurements, as they end up getting additional steal time that did not
> actually happen, from the previous excess steal time being paid back.
>
> For example, suppose a task in a VM runs for 10ms and had 15ms of steal
> time reported while it ran. clock_task rightly doesn't advance. Then, a
> different task runs on the same rq for 10ms without any time stolen.
> Because of the current catch up mechanism, clock_sched inaccurately ends
> up advancing by only 5ms instead of 10ms even though there wasn't any
> actual time stolen. The second task is getting charged for less time
> than it ran, even though it didn't deserve it.
> In other words, tasks can end up getting more run time than they should
> actually get.
>
> So, we instead don't make future updates pay back past excess stolen time.
My understanding was that it was done this way for a reason: there is a
lot of jitter between the "run time" (your 10ms example), and the steal
time (15ms). What if 5ms really *did* elapse between the time that
'delta' is calculated, and the call to paravirt_steal_clock()?
By accounting that steal time "in advance" we ensure it isn't lost in
the case where the same process remains running for the next timeslice.
However, that does cause problems when the steal time goes negative
(due to hypervisor bugs). So in
https://lore.kernel.org/all/20240522001817.619072-22-dwmw2@infradead.org/
I limited the amount of time which would be accounted to a future tick.
> Signed-off-by: Suleiman Souhlal <suleiman@google.com>
> ---
> kernel/sched/core.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index bcf2c4cc0522..42b37da2bda6 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -728,13 +728,15 @@ static void update_rq_clock_task(struct rq *rq, s64 delta)
> #endif
> #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
> if (static_key_false((¶virt_steal_rq_enabled))) {
> - steal = paravirt_steal_clock(cpu_of(rq));
> + u64 prev_steal;
> +
> + steal = prev_steal = paravirt_steal_clock(cpu_of(rq));
> steal -= rq->prev_steal_time_rq;
>
> if (unlikely(steal > delta))
> steal = delta;
>
> - rq->prev_steal_time_rq += steal;
> + rq->prev_steal_time_rq = prev_steal;
> delta -= steal;
> }
> #endif
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]
next prev parent reply other threads:[~2024-08-20 15:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-06 11:11 Suleiman Souhlal
2024-08-06 22:51 ` Joel Fernandes
2024-08-07 0:08 ` Suleiman Souhlal
2024-08-20 1:46 ` Suleiman Souhlal
2024-08-20 9:45 ` Srikar Dronamraju
2024-08-20 14:50 ` Steven Rostedt
2024-08-20 15:42 ` Joel Fernandes
2024-08-20 15:50 ` David Woodhouse [this message]
2024-08-23 21:52 ` Suleiman Souhlal
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=185314eedbe4e19a2a1cd7faf32b9a3a3e6acd07.camel@infradead.org \
--to=dwmw2@infradead.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=joelaf@google.com \
--cc=juri.lelli@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=ssouhlal@freebsd.org \
--cc=suleiman@google.com \
--cc=vincent.guittot@linaro.org \
--cc=vineethrp@google.com \
--cc=vschneid@redhat.com \
/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
all inboxes | Powered by JetHome®