From: Matthew Wilcox <matthew@wil.cx>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-mm@kvack.org, Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: [PATCH v4 21/22] Add support for pmd_faults
Date: Mon, 23 Dec 2013 11:42:22 -0700 [thread overview]
Message-ID: <20131223184222.GE11091@parisc-linux.org> (raw)
In-Reply-To: <20131223151003.GA15744@node.dhcp.inet.fi>
On Mon, Dec 23, 2013 at 05:10:03PM +0200, Kirill A. Shutemov wrote:
> On Mon, Dec 23, 2013 at 07:50:31AM -0700, Matthew Wilcox wrote:
> > On Mon, Dec 23, 2013 at 03:41:13PM +0200, Kirill A. Shutemov wrote:
> > > > + /* Fall back to PTEs if we're going to COW */
> > > > + if ((flags & FAULT_FLAG_WRITE) && !(vma->vm_flags & VM_SHARED))
> > > > + return VM_FAULT_FALLBACK;
> > >
> > > Why?
> >
> > If somebody mmaps a file with MAP_PRIVATE and changes a single byte, I
> > think we should allocate a single page to hold that change, not a PMD's
> > worth of pages.
>
> We try allocate new huge page in the same situation for AnonTHP. I don't
> see a reason why not to do the same here. It would be much harder (if
> possible) to collapse small page into a huge one later.
OK, I'll look at what AnonTHP does here. There may be good reasons to
do it differently, but in the absence of data, we should probably handle
the two cases the same.
> > > > + if ((pgoff | PG_PMD_COLOUR) >= size)
> > > > + return VM_FAULT_FALLBACK;
> > >
> > > I don't think it's necessary to fallback in this case.
> > > Do you care about SIGBUS behaviour or what?
> >
> > I'm looking to preserve the same behaviour we see with PTE mappings. I mean,
> > it's supposed to be _transparent_ huge pages, right?
>
> We can't be totally transparent. At least from performance point of view.
>
> The question is whether it's critical to preserve SIGBUS beheviour. I
> would prefer to map last page in mapping with huge pages too, if it's
> possible.
>
> Do you know anyone who relay on SIGBUS for correctness?
Oh, I remember the real reason now. If we install a PMD that hangs off
the end of the file then by reading past i_size, we can read the blocks of
whatever happens to be in storage after the end of the file, which could
be another file's data. This doesn't happen for the PTE case because the
existing code only works for filesystems with a block size == PAGE_SIZE.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
next prev parent reply other threads:[~2013-12-23 18:42 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-22 21:49 [PATCH v4 00/22] Add XIP support to ext4 Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 01/22] Fix XIP fault vs truncate race Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 02/22] Simplify COW of XIP mappings Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 03/22] axonram: Fix bug in direct_access Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 04/22] Change direct_access calling convention Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 05/22] Introduce IS_XIP(inode) Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 06/22] Treat XIP like O_DIRECT Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 07/22] Rewrite XIP page fault handling Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 08/22] Change xip_truncate_page to take a get_block parameter Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 09/22] Remove mm/filemap_xip.c Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 10/22] Remove get_xip_mem Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 11/22] Replace ext2_clear_xip_target with xip_clear_blocks Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 12/22] ext2: Remove ext2_xip_verify_sb() Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 13/22] ext2: Remove ext2_use_xip Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 14/22] ext2: Remove xip.c and xip.h Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 15/22] Remove CONFIG_EXT2_FS_XIP Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 16/22] ext2: Remove ext2_aops_xip Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 17/22] xip: Add xip_zero_page_range Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 18/22] ext4: Make ext4_block_zero_page_range static Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 19/22] ext4: Add XIP functionality Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 20/22] ext4: Fix typos Matthew Wilcox
2013-12-22 21:49 ` [PATCH v4 21/22] Add support for pmd_faults Matthew Wilcox
2013-12-23 13:41 ` Kirill A. Shutemov
2013-12-23 14:50 ` Matthew Wilcox
2013-12-23 15:04 ` Matthew Wilcox
2013-12-23 15:11 ` Kirill A. Shutemov
2013-12-23 15:10 ` Kirill A. Shutemov
2013-12-23 18:42 ` Matthew Wilcox [this message]
2013-12-23 18:54 ` Kirill A. Shutemov
2013-12-22 21:49 ` [PATCH v4 22/22] xip: Add reporting of major faults 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=20131223184222.GE11091@parisc-linux.org \
--to=matthew@wil.cx \
--cc=aarcange@redhat.com \
--cc=kirill@shutemov.name \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.r.wilcox@intel.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;
as well as URLs for NNTP newsgroup(s).