From: Matthew Wilcox <willy@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: Michael Larabel <Michael@michaellarabel.com>,
Amir Goldstein <amir73il@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ted Ts'o <tytso@google.com>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: Kernel Benchmarking
Date: Tue, 15 Sep 2020 14:52:46 +0100 [thread overview]
Message-ID: <20200915135246.GG5449@casper.infradead.org> (raw)
In-Reply-To: <20200915103938.GL4863@quack2.suse.cz>
On Tue, Sep 15, 2020 at 12:39:38PM +0200, Jan Kara wrote:
> Hi Matthew!
>
> On Tue 15-09-20 04:32:10, Matthew Wilcox wrote:
> > On Sat, Sep 12, 2020 at 09:44:15AM -0500, Michael Larabel wrote:
> > > Interesting, I'll fire up some cross-filesystem benchmarks with those tests
> > > today and report back shortly with the difference.
> >
> > If you have time, perhaps you'd like to try this patch. It tries to
> > handle page faults locklessly when possible, which should be the case
> > where you're seeing page lock contention. I've tried to be fairly
> > conservative in this patch; reducing page lock acquisition should be
> > possible in more cases.
>
> So I'd be somewhat uneasy with this optimization. The thing is that e.g.
> page migration relies on page lock protecting page from being mapped? How
> does your patch handle that? I'm also not sure if the rmap code is really
> ready for new page reverse mapping being added without holding page lock...
I admit to not even having looked at the page migration code. This
patch was really to demonstrate that it's _possible_ to do page faults
without taking the page lock.
It's possible to expand the ClearPageUptodate page validity protocol
beyond mm/truncate.c, of course. We can find all necessary places to
change by grepping for 'page_mapped'. Some places (eg the invalidate2
path) can't safely ClearPageUptodate before their existing call to
unmap_mapping_pages(), and those places will have to add a second
test-and-call.
It seems to me the page_add_file_rmap() is fine with being called
without the page lock, unless the page is compound. So we could
make sure not to use this new protocol for THPs ...
+++ b/mm/filemap.c
@@ -2604,7 +2604,7 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
if (fpin)
goto out_retry;
- if (likely(PageUptodate(page))) {
+ if (likely(PageUptodate(page) && !PageTransHuge(page))) {
ret |= VM_FAULT_UPTODATE;
goto uptodate;
}
diff --git a/mm/memory.c b/mm/memory.c
index 53c8ef2bb38b..6981e8738df4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3460,6 +3460,9 @@ static vm_fault_t __do_fault(struct vm_fault *vmf)
return VM_FAULT_HWPOISON;
}
+ /* rmap needs THP pages to be locked in case it's mlocked */
+ VM_BUG_ON((ret & VM_FAULT_UPTODATE) && PageTransHuge(page));
+
return ret;
}
next prev parent reply other threads:[~2020-09-16 0:27 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAHk-=wiZnE409WkTOG6fbF_eV1LgrHBvMtyKkpTqM9zT5hpf9A@mail.gmail.com>
[not found] ` <4ced9401-de3d-b7c9-9976-2739e837fafc@MichaelLarabel.com>
[not found] ` <CAHk-=wj+Qj=wXByMrAx3T8jmw=soUetioRrbz6dQaECx+zjMtg@mail.gmail.com>
[not found] ` <CAHk-=wgOPjbJsj-LeLc-JMx9Sz9DjGF66Q+jQFJROt9X9utdBg@mail.gmail.com>
[not found] ` <CAHk-=wjjK7PTnDZNi039yBxSHtAqusFoRrZzgMNTiYkJYdNopw@mail.gmail.com>
[not found] ` <aa90f272-1186-f9e1-8fdb-eefd332fdae8@MichaelLarabel.com>
[not found] ` <CAHk-=wh_31_XBNHbdF7EUJceLpEpwRxVF+_1TONzyBUym6Pw4w@mail.gmail.com>
[not found] ` <e24ef34d-7b1d-dd99-082d-28ca285a79ff@MichaelLarabel.com>
[not found] ` <CAHk-=wgEE4GuNjcRaaAvaS97tW+239-+tjcPjTq2FGhEuM8HYg@mail.gmail.com>
[not found] ` <6e1d8740-2594-c58b-ff02-a04df453d53c@MichaelLarabel.com>
[not found] ` <CAHk-=wgJ3-cEkU-5zXFPvRCHKkCCuKxVauYWGphjePEhJJgtgQ@mail.gmail.com>
[not found] ` <d2023f4c-ef14-b877-b5bb-e4f8af332abc@MichaelLarabel.com>
[not found] ` <CAHk-=wiz=J=8mJ=zRG93nuJ9GtQAm5bSRAbWJbWZuN4Br38+EQ@mail.gmail.com>
2020-09-11 0:05 ` Kernel Benchmarking Linus Torvalds
2020-09-11 0:49 ` Michael Larabel
2020-09-11 2:20 ` Linus Torvalds
[not found] ` <0cbc959e-1b8d-8d7e-1dc6-672cf5b3899a@MichaelLarabel.com>
2020-09-11 16:19 ` Linus Torvalds
2020-09-11 22:07 ` Linus Torvalds
2020-09-11 22:37 ` Michael Larabel
2020-09-12 7:28 ` Amir Goldstein
2020-09-12 10:32 ` Michael Larabel
2020-09-12 14:37 ` Matthew Wilcox
2020-09-12 14:44 ` Michael Larabel
2020-09-15 3:32 ` Matthew Wilcox
2020-09-15 10:39 ` Jan Kara
2020-09-15 13:52 ` Matthew Wilcox [this message]
[not found] ` <658ae026-32d9-0a25-5a59-9c510d6898d5@MichaelLarabel.com>
2020-09-14 17:47 ` Linus Torvalds
2020-09-14 20:21 ` Matthieu Baerts
2020-09-14 20:53 ` Linus Torvalds
2020-09-15 0:42 ` Linus Torvalds
2020-09-15 15:34 ` Matthieu Baerts
2020-09-15 18:27 ` Linus Torvalds
2020-09-15 18:47 ` Linus Torvalds
2020-09-15 19:26 ` Matthieu Baerts
2020-09-15 19:32 ` Linus Torvalds
2020-09-15 19:56 ` Matthieu Baerts
2020-09-15 23:35 ` Linus Torvalds
2020-09-16 10:34 ` Jan Kara
2020-09-16 18:47 ` Linus Torvalds
[not found] ` <9a92bf16-02c5-ba38-33c7-f350588ac874@tessares.net>
2020-09-15 19:24 ` Linus Torvalds
2020-09-15 19:38 ` Matthieu Baerts
2020-09-15 18:31 ` Linus Torvalds
2020-09-15 14:21 ` Michael Larabel
2020-09-15 17:52 ` Linus Torvalds
2020-09-17 17:51 ` Linus Torvalds
2020-09-17 18:23 ` Matthew Wilcox
2020-09-17 18:30 ` Linus Torvalds
2020-09-17 18:50 ` Matthew Wilcox
2020-09-17 19:00 ` Linus Torvalds
2020-09-17 19:27 ` Matthew Wilcox
2020-09-17 19:47 ` Linus Torvalds
2020-09-18 0:39 ` Sedat Dilek
2020-09-18 0:40 ` Sedat Dilek
2020-09-18 20:25 ` Sedat Dilek
2020-09-20 17:06 ` Linus Torvalds
2020-09-20 17:14 ` Sedat Dilek
2020-09-20 17:40 ` Linus Torvalds
2020-09-20 18:00 ` Sedat Dilek
2020-09-20 23:23 ` Dave Chinner
2020-09-20 23:31 ` Linus Torvalds
2020-09-20 23:40 ` Linus Torvalds
2020-09-21 1:20 ` Dave Chinner
2020-09-12 15:53 ` Matthew Wilcox
2020-09-12 17:59 ` Linus Torvalds
2020-09-12 20:32 ` Rogério Brito
2020-09-14 9:33 ` Jan Kara
2020-09-12 20:58 ` Josh Triplett
2020-09-12 20:59 ` James Bottomley
2020-09-12 21:15 ` Linus Torvalds
2020-09-12 22:32 ` Matthew Wilcox
2020-09-13 0:40 ` Dave Chinner
2020-09-13 2:39 ` Linus Torvalds
2020-09-13 3:40 ` Matthew Wilcox
2020-09-13 23:45 ` Dave Chinner
2020-09-14 3:31 ` Matthew Wilcox
2020-09-15 14:28 ` Chris Mason
2020-09-15 9:27 ` Jan Kara
2020-09-13 3:18 ` Matthew Wilcox
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=20200915135246.GG5449@casper.infradead.org \
--to=willy@infradead.org \
--cc=Michael@michaellarabel.com \
--cc=adilger.kernel@dilger.ca \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@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 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.