From: Jason Gunthorpe <jgg@ziepe.ca>
To: David Woodhouse <dwmw2@infradead.org>
Cc: akpm@linux-foundation.org, david@kernel.org, mhocko@suse.com,
rostedt@goodmis.org, bigeasy@linutronix.de,
simona.vetter@ffwll.ch, jglisse@redhat.com,
christian.koenig@amd.com, paulmck@kernel.org, seanjc@google.com,
pbonzini@redhat.com, linux-mm@kvack.org, kvm@vger.kernel.org,
linux-rt-devel@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/mmu_notifier: Remove non_block_start/end() from notifier invocation
Date: Tue, 11 Aug 2026 14:26:27 -0300 [thread overview]
Message-ID: <20260811172627.GN544626@ziepe.ca> (raw)
In-Reply-To: <f33571137d2e3973e440d09c7602edaebe08b714.camel@infradead.org>
On Tue, Aug 11, 2026 at 06:22:12PM +0100, David Woodhouse wrote:
> On Tue, 2026-08-11 at 13:24 -0300, Jason Gunthorpe wrote:
> > To be clear you should not be using any synchronize_[s]rcu() primitive
> > inside the invalidation callbacks. These are well known to have
> > multi-second delays on loaded systems which are a completely
> > inappropriate performance characteristic for these mm callbacks.
> >
> > This statement has nothing to do with deadlock.
> >
> > RCU is always a trade off, you can make the read side run really fast
> > and the write side is ghastly slow. If you can't handle the slow write
> > you shouldn't use RCU techniques.
>
> The multi-second horror stories are about the *global* RCU/SRCU
> domains, where the grace period has to wait out arbitrary readers all
> over the kernel.
>
> This is not that. It is a dedicated srcu_struct, private to one VM,
> and its entire reader population is a handful of KVM fast paths that
> until now were under irqsave rwlocks.
Are you sure? I've never heard that srcu has those kinds of properties.
If its so fast you should just propose a non-sleeping version and
leave the notifiers out of it
Jason
next prev parent reply other threads:[~2026-08-11 17:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 8:58 [PATCH] mm/mmu_notifier: Remove non_block_start/end() from notifier invocation David Woodhouse
2026-08-11 13:55 ` Jason Gunthorpe
2026-08-11 14:21 ` David Woodhouse
2026-08-11 14:27 ` Jason Gunthorpe
2026-08-11 14:33 ` David Woodhouse
2026-08-11 14:42 ` Steven Rostedt
2026-08-11 15:24 ` David Woodhouse
2026-08-11 15:30 ` Jason Gunthorpe
2026-08-11 15:29 ` Jason Gunthorpe
2026-08-11 15:15 ` David Woodhouse
2026-08-11 15:24 ` Jason Gunthorpe
2026-08-11 15:29 ` David Woodhouse
2026-08-11 16:24 ` Jason Gunthorpe
2026-08-11 17:22 ` David Woodhouse
2026-08-11 17:26 ` Jason Gunthorpe [this message]
2026-08-11 17:59 ` David Woodhouse
2026-08-11 18:19 ` Jason Gunthorpe
2026-08-11 20:06 ` Sean Christopherson
2026-08-11 20:21 ` Paolo Bonzini
2026-08-11 21:14 ` David Woodhouse
2026-08-11 22:58 ` Sean Christopherson
2026-08-11 23:50 ` David Woodhouse
2026-08-11 20:29 ` David Woodhouse
2026-08-11 15:12 ` David Hildenbrand (Arm)
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=20260811172627.GN544626@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=christian.koenig@amd.com \
--cc=david@kernel.org \
--cc=dwmw2@infradead.org \
--cc=jglisse@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=mhocko@suse.com \
--cc=paulmck@kernel.org \
--cc=pbonzini@redhat.com \
--cc=rostedt@goodmis.org \
--cc=seanjc@google.com \
--cc=simona.vetter@ffwll.ch \
/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.