linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@linux.intel.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Matthew Wilcox <willy@linux.intel.com>,
	Matthew Wilcox <matthew.r.wilcox@intel.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH v1 2/7] mm: Prepare for DAX huge pages
Date: Thu, 9 Oct 2014 16:40:26 -0400	[thread overview]
Message-ID: <20141009204026.GP5098@wil.cx> (raw)
In-Reply-To: <20141008194335.GA9232@node.dhcp.inet.fi>

On Wed, Oct 08, 2014 at 10:43:35PM +0300, Kirill A. Shutemov wrote:
> On Wed, Oct 08, 2014 at 11:57:58AM -0400, Matthew Wilcox wrote:
> > On Wed, Oct 08, 2014 at 06:21:24PM +0300, Kirill A. Shutemov wrote:
> > > On Wed, Oct 08, 2014 at 09:25:24AM -0400, Matthew Wilcox wrote:
> > > > From: Matthew Wilcox <willy@linux.intel.com>
> > > > 
> > > > DAX wants to use the 'special' bit to mark PMD entries that are not backed
> > > > by struct page, just as for PTEs. 
> > > 
> > > Hm. I don't see where you use PMD without special set.
> > 
> > Right ... I don't currently insert PMDs that point to huge pages of DRAM,
> > only to huge pages of PMEM.
> 
> Looks like you don't need pmd_{mk,}special() then. It seems you have all
> inforamtion you need -- vma -- to find out what's going on. Right?

That would prevent us from putting huge pages of DRAM into a VM_MIXEDMAP |
VM_HUGEPAGE vma.  Is that acceptable to the wider peanut gallery?

> > > No private THP pages with THP? Why?
> > > It should be trivial: we already have a code path for !page case for zero
> > > page and it shouldn't be too hard to modify do_dax_pmd_fault() to support
> > > COW.
> > > 
> > > I remeber I've mentioned that you don't think it's reasonable to allocate
> > > 2M page on COW, but that's what we do for anon memory...
> > 
> > I agree that it shouldn't be too hard, but I have no evidence that it'll
> > be a performance win to COW 2MB pages for MAP_PRIVATE.  I'd rather be
> > cautious for now and we can explore COWing 2MB chunks in a future patch.
> 
> I would rather make it other way around: use the same apporoach as for
> anon memory until data shows it's doesn't make any good. Then consider
> switching COW for *both* anon and file THP to fallback path.
> This way we will get consistent behaviour for both types of mappings.

I'm not sure that we want consistent behaviour for both types of mappings.
My understanding is that they're used for different purposes, and having
different bahaviour is acceptable.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2014-10-09 20:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-08 13:25 [PATCH v1 0/7] Huge page support for DAX Matthew Wilcox
2014-10-08 13:25 ` [PATCH v1 1/7] thp: vma_adjust_trans_huge(): adjust file-backed VMA too Matthew Wilcox
2014-10-08 13:25 ` [PATCH v1 2/7] mm: Prepare for DAX huge pages Matthew Wilcox
2014-10-08 15:21   ` Kirill A. Shutemov
2014-10-08 15:57     ` Matthew Wilcox
2014-10-08 19:43       ` Kirill A. Shutemov
2014-10-09 20:40         ` Matthew Wilcox [this message]
2014-10-13 20:36           ` Kirill A. Shutemov
2014-10-08 13:25 ` [PATCH v1 3/7] mm: Add vm_insert_pfn_pmd() Matthew Wilcox
2014-10-08 13:25 ` [PATCH v1 4/7] mm: Add a pmd_fault handler Matthew Wilcox
2014-10-08 13:25 ` [PATCH v1 5/7] dax: Add huge page fault support Matthew Wilcox
2014-10-08 20:11   ` Kirill A. Shutemov
2014-10-09 20:47     ` Matthew Wilcox
2014-10-13  1:13       ` Dave Chinner
2014-10-08 13:25 ` [PATCH v1 6/7] ext2: Huge " Matthew Wilcox
2014-10-08 13:25 ` [PATCH v1 7/7] ext4: " 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=20141009204026.GP5098@wil.cx \
    --to=willy@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@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).