public inbox for rcu@vger.kernel.org
 help / color / mirror / Atom feed
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


  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