linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
Subject: Re: [PATCH v4 21/22] Add support for pmd_faults
Date: Mon, 23 Dec 2013 07:50:31 -0700	[thread overview]
Message-ID: <20131223145031.GB11091@parisc-linux.org> (raw)
In-Reply-To: <20131223134113.GA14806@node.dhcp.inet.fi>

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.

> > +	pgoff = ((address - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
> > +	size = (i_size_read(inode) + PAGE_SIZE - 1) >> PAGE_SHIFT;
> > +	if (pgoff >= size)
> > +		return VM_FAULT_SIGBUS;
> > +	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?

> > + insert:
> > +	length = xip_get_pfn(inode, &bh, &pfn);
> > +	if (length < 0)
> > +		return VM_FAULT_SIGBUS;
> > +	if (length < PMD_SIZE)
> > +		return VM_FAULT_FALLBACK;
> > +	if (pfn & PG_PMD_COLOUR)
> > +		return VM_FAULT_FALLBACK;	/* not aligned */
> 
> Without assistance from get_unmapped_area() you will hit this all the time
> (511 of 512 on x86_64).

Yes ... I thought you were working on that part for your transparent huge
page cache patchset?

> And the check should be moved before get_block(), I think.

Can't.  The PFN we're checking is the PFN of the storage.  We have to
call get_block() to find out where it's going to be.

> > +static int insert_pfn_pmd(struct vm_area_struct *vma, unsigned long addr,
> > +			pmd_t *pmd, unsigned long pfn, pgprot_t prot)
> > +{
> > +	struct mm_struct *mm = vma->vm_mm;
> > +	int retval;
> > +	pmd_t entry;
> > +	spinlock_t *ptl;
> > +
> > +	ptl = pmd_lock(mm, pmd);
> > +	retval = -EBUSY;
> > +	if (!pmd_none(*pmd))
> > +		goto out_unlock;
> > +
> > +	/* Ok, finally just insert the thing.. */
> > +	entry = pfn_pmd(pfn, prot); /* XXX: pmd_mkspecial? */
> > +	set_pmd_at(mm, addr, pmd, entry);
> > +	update_mmu_cache_pmd(vma, addr, pmd);
> 
> Here you need to allocate pgtable and deposit it to be able to split the page.

You've mentioned that in the past, and looking at it further is on my
todo list.

-- 
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."

  reply	other threads:[~2013-12-23 14:50 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 [this message]
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
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=20131223145031.GB11091@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=kirill@shutemov.name \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.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).