From: Kunwu Chan <kunwu.chan@linux.dev>
To: Sean Christopherson <seanjc@google.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: rcu@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org,
Nikita Kalyazin <kalyazin@amazon.com>,
Keir Fraser <keirf@google.com>
Subject: Re: [RFC PATCH 0/3] srcu: KVM: Add, export and use call_srcu_expedited()
Date: Fri, 13 Mar 2026 16:51:22 +0800 [thread overview]
Message-ID: <067c53cc-b015-43c6-9ba3-c734eff17819@linux.dev> (raw)
In-Reply-To: <20260309193059.2244645-1-seanjc@google.com>
On 3/10/26 03:30, Sean Christopherson wrote:
> We've got a conundrum in KVM where we have multiple use cases that generally
> want the same thing (eliminate waiting on guest configuration changes whenever
> possible), but use KVM uAPIs in slightly different ways and effectively create
> competing requirements.
>
> The crux of the problem is that one use case wants KVM to free an object via
> call_srcu() so that the task doesn't risk getting stalled waiting for a grace
> period. But for the other use case, using call_srcu() can trigger a
> non-expedited grace period and cause a synchronize_srcu_expedited() in a
> different ioctl (that must do a full sync, i.e. can't use call_srcu()) to stall
> waiting for the non-expedited grace period.
>
> Tagged RFC because while having the call_srcu() request do an expedited grace
> period eliminates the unwanted synchronize_srcu_expedited() stalls, this feels
> like a very crude fix. That said, I'm definitely not opposed to this being a
> final solution if it's the best option available.
>
> Sean Christopherson (3):
> srcu: Declare exported symbols before including srcu{tiny,tree}.h
> srcu: Add and export call_srcu_expedited() to avoid transferring grace
> periods
Hi,
Thanks for writing this up.
The scenario you describe looks plausible.
That said, the cover letter wording might be a bit stronger than
current SRCU behavior warrants. A later synchronize_srcu_expedited()
can attempt to expedite an in-flight grace period, but it cannot
avoid delay already incurred (for example, if the GP has already
gone to sleep).
More generally, before adding an exported call_srcu_expedited()
helper, should we consider improving existing in-flight promotion
or delay behavior, or otherwise making the "expedite current GP"
case more explicit without introducing a new callback-facing API?
Thanx, Kunwu
> KVM: Expedite SRCU callbacks when freeing objects during I/O bus
> registration
>
> include/linux/srcu.h | 10 +++++-----
> include/linux/srcutiny.h | 8 ++++++--
> include/linux/srcutree.h | 2 ++
> kernel/rcu/srcutree.c | 7 +++++++
> virt/kvm/kvm_main.c | 2 +-
> 5 files changed, 21 insertions(+), 8 deletions(-)
>
>
> base-commit: 5128b972fb2801ad9aca54d990a75611ab5283a9
next prev parent reply other threads:[~2026-03-13 8:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-09 19:30 [RFC PATCH 0/3] srcu: KVM: Add, export and use call_srcu_expedited() Sean Christopherson
2026-03-09 19:30 ` [RFC PATCH 1/3] srcu: Declare exported symbols before including srcu{tiny,tree}.h Sean Christopherson
2026-03-09 19:30 ` [RFC PATCH 2/3] srcu: Add and export call_srcu_expedited() to avoid transferring grace periods Sean Christopherson
2026-03-09 19:30 ` [RFC PATCH 3/3] KVM: Expedite SRCU callbacks when freeing objects during I/O bus registration Sean Christopherson
2026-03-13 8:51 ` Kunwu Chan [this message]
2026-03-13 23:12 ` [RFC PATCH 0/3] srcu: KVM: Add, export and use call_srcu_expedited() Sean Christopherson
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=067c53cc-b015-43c6-9ba3-c734eff17819@linux.dev \
--to=kunwu.chan@linux.dev \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=kalyazin@amazon.com \
--cc=keirf@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=pbonzini@redhat.com \
--cc=rcu@vger.kernel.org \
--cc=seanjc@google.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