From: Matthew Wilcox <willy@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Larabel <Michael@michaellarabel.com>,
Matthieu Baerts <matthieu.baerts@tessares.net>,
Amir Goldstein <amir73il@gmail.com>, Ted Ts'o <tytso@google.com>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
Jan Kara <jack@suse.cz>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: Kernel Benchmarking
Date: Thu, 17 Sep 2020 19:50:49 +0100 [thread overview]
Message-ID: <20200917185049.GV5449@casper.infradead.org> (raw)
In-Reply-To: <CAHk-=wj6g2y2Z3cGzHBMoeLx-mfG0Md_2wMVwx=+g_e-xDNTbw@mail.gmail.com>
On Thu, Sep 17, 2020 at 11:30:00AM -0700, Linus Torvalds wrote:
> On Thu, Sep 17, 2020 at 11:23 AM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > Something like taking
> > the i_mmap_lock_read(file->f_mapping) in filemap_fault, then adding a
> > new VM_FAULT_I_MMAP_LOCKED bit so that do_read_fault() and friends add:
> >
> > if (ret & VM_FAULT_I_MMAP_LOCKED)
> > i_mmap_unlock_read(vmf->vma->vm_file->f_mapping);
> > else
> > unlock_page(page);
> >
> > ... want me to turn that into a real patch?
>
> I can't guarantee it's the right model - it does worry me how many
> places we might get that i_mmap_rwlock, and how long we migth hold it
> for writing, and what deadlocks it might cause when we take it for
> reading in the page fault path.
>
> But I think it might be very interesting as a benchmark patch and a
> trial balloon. Maybe it "just works".
Ahh. Here's a race this doesn't close:
int truncate_inode_page(struct address_space *mapping, struct page *page)
{
VM_BUG_ON_PAGE(PageTail(page), page);
if (page->mapping != mapping)
return -EIO;
truncate_cleanup_page(mapping, page);
delete_from_page_cache(page);
return 0;
}
truncate_cleanup_page() does
if (page_mapped(page)) {
pgoff_t nr = PageTransHuge(page) ? HPAGE_PMD_NR : 1;
unmap_mapping_pages(mapping, page->index, nr, false);
}
but ->mapping isn't cleared until delete_from_page_cache() many
instructions later. So we can get the lock and have a page which appears
to be not-truncated, only for it to get truncated on us later.
> I would _love_ for the page lock itself to be only (or at least
> _mainly_) about the actual IO synchronization on the page.
>
> That was the origin of it, the whole "protect all the complex state of
> a page" behavior kind of grew over time, since it was the only
> per-page lock we had.
Yes, I think that's a noble goal.
next prev parent reply other threads:[~2020-09-17 18:51 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
[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 [this message]
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=20200917185049.GV5449@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=matthieu.baerts@tessares.net \
--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.