From: Sean Christopherson <seanjc@google.com>
To: Dongli Zhang <dongli.zhang@oracle.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
pbonzini@redhat.com, peterz@infradead.org,
juri.lelli@redhat.com, vincent.guittot@linaro.org,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
kprateek.nayak@amd.com, dwmw2@infradead.org, joe.jin@oracle.com
Subject: Re: [PATCH RFC 2/2] sched/core: Defer preempted remote vCPU task clock updates
Date: Mon, 21 Sep 2026 08:59:08 -0700 [thread overview]
Message-ID: <arFUTBLuLdVVaqxX@google.com> (raw)
In-Reply-To: <20260824012716.753022-3-dongli.zhang@oracle.com>
On Sun, Aug 23, 2026, Dongli Zhang wrote:
> A remote update of a runqueue can advance rq->clock while the owner
> vCPU is still preempted by the host. KVM publishes the matching stealtime
> when the vCPU is about to re-enter the guest, so the remote CPU can
> otherwise charge the stolen interval to rq->clock_task.
>
> Defer clock_task updates made by a remote CPU while the owner vCPU is
> reported preempted. Fold the deferred delta back into the next update
> that can proceed so IRQ and steal accounting process it together.
>
> This requires the hypervisor to publish up-to-date stealtime before
> clearing the preempted data.
What happens if the hypervisor doesn't do that? Because it's infeasible to
guarantee this will never run on an older version of KVM.
prev parent reply other threads:[~2026-09-21 15:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 1:26 [PATCH RFC 0/2] Fix KVM guest scheduling accounting issue related to stealtime Dongli Zhang
2026-08-24 1:26 ` [PATCH RFC 1/2] KVM: x86: Update stealtime before clearing preempted state Dongli Zhang
2026-08-24 1:26 ` [PATCH RFC 2/2] sched/core: Defer preempted remote vCPU task clock updates Dongli Zhang
2026-09-21 15:59 ` Sean Christopherson [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=arFUTBLuLdVVaqxX@google.com \
--to=seanjc@google.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=dongli.zhang@oracle.com \
--cc=dwmw2@infradead.org \
--cc=joe.jin@oracle.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--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®