From: Jason Gunthorpe <jgg@ziepe.ca>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Freeing page tables through RCU
Date: Fri, 26 Feb 2021 12:21:43 -0400 [thread overview]
Message-ID: <20210226162143.GW2643399@ziepe.ca> (raw)
In-Reply-To: <20210226160354.GE2723601@casper.infradead.org>
On Fri, Feb 26, 2021 at 04:03:54PM +0000, Matthew Wilcox wrote:
> On Fri, Feb 26, 2021 at 10:42:00AM -0400, Jason Gunthorpe wrote:
> > On Thu, Feb 25, 2021 at 08:58:20PM +0000, Matthew Wilcox wrote:
> >
> > > I'd like to hear better ideas than this.
> >
> > You didn't like my suggestion to put a sleepable lock around the
> > freeing of page tables during flushing?
> >
> > I still don't see how you convert the sleepable page walkers to use
> > rcu??
>
> I don't want to convert the sleepable ones to use RCU ... I want to
> convert the non-sleeping ones to use RCU.
Why? Convert them to use the normal page table spinlocks?
It makes everything much more understandable if it is locked properly.
The lockless walks should be reserved for special places because they
are actually hard to do properly.
> A page_table_free_lock might work, but it might have its own
> problems later (eg a sleeping lock can't be acquired under RCU or
> spinlock, and it can't be a spinlock because it'd have to be held
> while we wait for IPIs).
The mmap_sem today is serving the function of the page_table_free_lock
idea, so I think a sleepable lock is already proven to work?
Jason
next prev parent reply other threads:[~2021-02-26 16:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-25 20:58 Freeing page tables through RCU Matthew Wilcox
2021-02-26 14:42 ` Jason Gunthorpe
2021-02-26 16:03 ` Matthew Wilcox
2021-02-26 16:21 ` Jason Gunthorpe [this message]
2021-02-26 16:12 ` Gerald Schaefer
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=20210226162143.GW2643399@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=willy@infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).