All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-xfs@vger.kernel.org,
	Matthew Wilcox <mawilcox@microsoft.com>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Christoph Hellwig <hch@infradead.org>,
	Linux MM <linux-mm@kvack.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Jan Kara <jack@suse.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-ext4 <linux-ext4@vger.kernel.org>,
	Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH] mm: replace FAULT_FLAG_SIZE with parameter to huge_fault
Date: Tue, 7 Feb 2017 11:44:11 +0300	[thread overview]
Message-ID: <20170207084411.GA527@node.shutemov.name> (raw)
In-Reply-To: <CAPcyv4hiwWebCT=qPccKqaQKAHydMYsg9+=pYh=SPkNzakLc1A@mail.gmail.com>

On Mon, Feb 06, 2017 at 09:30:22AM -0800, Dan Williams wrote:
> On Mon, Feb 6, 2017 at 9:27 AM, Christoph Hellwig <hch@infradead.org> wrote:
> > On Mon, Feb 06, 2017 at 08:24:48AM -0800, Dan Williams wrote:
> >> > Also can be use this opportunity
> >> > to fold ->huge_fault into ->fault?

BTW, for tmpfs we already use ->fault for both small and huge pages.
If ->fault returned THP, core mm look if it's possible to map the page as
huge in this particular VMA (due to size/alignment). If yes mm maps the
page with PMD, if not fallback to PTE.

I think it would be nice to do the same for DAX: filesystem provides core
mm with largest page this part of file can be mapped with (base aligned
address + lenght for DAX) and core mm sort out the rest.

> >> Hmm, yes, just need a scheme to not attempt huge_faults on pte-only handlers.
> >
> > Do we need anything more than checking vma->vm_flags for VM_HUGETLB?
> 
> s/VM_HUGETLB/VM_HUGEPAGE/
> 
> ...but yes as long as we specify that a VM_HUGEPAGE handler must
> minimally handle pud and pmd.

VM_HUGEPAGE is result of MADV_HUGEPAGE. It's not required to have THP in
the VMA.

-- 
 Kirill A. Shutemov
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	linux-xfs@vger.kernel.org, Linux MM <linux-mm@kvack.org>,
	Vlastimil Babka <vbabka@suse.cz>, Jan Kara <jack@suse.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-ext4 <linux-ext4@vger.kernel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH] mm: replace FAULT_FLAG_SIZE with parameter to huge_fault
Date: Tue, 7 Feb 2017 11:44:11 +0300	[thread overview]
Message-ID: <20170207084411.GA527@node.shutemov.name> (raw)
In-Reply-To: <CAPcyv4hiwWebCT=qPccKqaQKAHydMYsg9+=pYh=SPkNzakLc1A@mail.gmail.com>

On Mon, Feb 06, 2017 at 09:30:22AM -0800, Dan Williams wrote:
> On Mon, Feb 6, 2017 at 9:27 AM, Christoph Hellwig <hch@infradead.org> wrote:
> > On Mon, Feb 06, 2017 at 08:24:48AM -0800, Dan Williams wrote:
> >> > Also can be use this opportunity
> >> > to fold ->huge_fault into ->fault?

BTW, for tmpfs we already use ->fault for both small and huge pages.
If ->fault returned THP, core mm look if it's possible to map the page as
huge in this particular VMA (due to size/alignment). If yes mm maps the
page with PMD, if not fallback to PTE.

I think it would be nice to do the same for DAX: filesystem provides core
mm with largest page this part of file can be mapped with (base aligned
address + lenght for DAX) and core mm sort out the rest.

> >> Hmm, yes, just need a scheme to not attempt huge_faults on pte-only handlers.
> >
> > Do we need anything more than checking vma->vm_flags for VM_HUGETLB?
> 
> s/VM_HUGETLB/VM_HUGEPAGE/
> 
> ...but yes as long as we specify that a VM_HUGEPAGE handler must
> minimally handle pud and pmd.

VM_HUGEPAGE is result of MADV_HUGEPAGE. It's not required to have THP in
the VMA.

-- 
 Kirill A. Shutemov

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

WARNING: multiple messages have this Message-ID (diff)
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	linux-xfs@vger.kernel.org, Linux MM <linux-mm@kvack.org>,
	Vlastimil Babka <vbabka@suse.cz>, Jan Kara <jack@suse.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-ext4 <linux-ext4@vger.kernel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH] mm: replace FAULT_FLAG_SIZE with parameter to huge_fault
Date: Tue, 7 Feb 2017 11:44:11 +0300	[thread overview]
Message-ID: <20170207084411.GA527@node.shutemov.name> (raw)
In-Reply-To: <CAPcyv4hiwWebCT=qPccKqaQKAHydMYsg9+=pYh=SPkNzakLc1A@mail.gmail.com>

On Mon, Feb 06, 2017 at 09:30:22AM -0800, Dan Williams wrote:
> On Mon, Feb 6, 2017 at 9:27 AM, Christoph Hellwig <hch@infradead.org> wrote:
> > On Mon, Feb 06, 2017 at 08:24:48AM -0800, Dan Williams wrote:
> >> > Also can be use this opportunity
> >> > to fold ->huge_fault into ->fault?

BTW, for tmpfs we already use ->fault for both small and huge pages.
If ->fault returned THP, core mm look if it's possible to map the page as
huge in this particular VMA (due to size/alignment). If yes mm maps the
page with PMD, if not fallback to PTE.

I think it would be nice to do the same for DAX: filesystem provides core
mm with largest page this part of file can be mapped with (base aligned
address + lenght for DAX) and core mm sort out the rest.

> >> Hmm, yes, just need a scheme to not attempt huge_faults on pte-only handlers.
> >
> > Do we need anything more than checking vma->vm_flags for VM_HUGETLB?
> 
> s/VM_HUGETLB/VM_HUGEPAGE/
> 
> ...but yes as long as we specify that a VM_HUGEPAGE handler must
> minimally handle pud and pmd.

VM_HUGEPAGE is result of MADV_HUGEPAGE. It's not required to have THP in
the VMA.

-- 
 Kirill A. Shutemov

  reply	other threads:[~2017-02-07  8:44 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-03 21:31 [PATCH] mm: replace FAULT_FLAG_SIZE with parameter to huge_fault Dave Jiang
2017-02-03 21:31 ` Dave Jiang
2017-02-03 21:31 ` Dave Jiang
2017-02-03 21:31 ` Dave Jiang
2017-02-03 21:47 ` Dan Williams
2017-02-03 21:47   ` Dan Williams
2017-02-03 21:47   ` Dan Williams
2017-02-03 22:56 ` kbuild test robot
2017-02-03 22:56   ` kbuild test robot
2017-02-03 22:56   ` kbuild test robot
2017-02-03 23:25   ` Dave Jiang
2017-02-03 23:25     ` Dave Jiang
2017-02-03 23:25     ` Dave Jiang
2017-02-03 23:26     ` Dan Williams
2017-02-03 23:26       ` Dan Williams
2017-02-04  0:00       ` Dan Williams
2017-02-04  0:00         ` Dan Williams
2017-02-04  0:00         ` Dan Williams
2017-02-04  0:07         ` Dave Jiang
2017-02-04  0:07           ` Dave Jiang
2017-02-04  0:07           ` Dave Jiang
2017-02-09  4:34           ` [kbuild-all] " Ye Xiaolong
2017-02-09  4:34             ` Ye Xiaolong
2017-02-09  4:34             ` Ye Xiaolong
2017-02-09  4:34             ` Ye Xiaolong
2017-02-04  3:51 ` kbuild test robot
2017-02-04  3:51   ` kbuild test robot
2017-02-04  3:51   ` kbuild test robot
2017-02-06  8:51 ` Jan Kara
2017-02-06  8:51   ` Jan Kara
2017-02-06  8:51   ` Jan Kara
2017-02-06  8:51   ` Jan Kara
2017-02-06 14:36 ` Christoph Hellwig
2017-02-06 14:36   ` Christoph Hellwig
2017-02-06 14:36   ` Christoph Hellwig
2017-02-06 14:36   ` Christoph Hellwig
2017-02-06 16:24   ` Dan Williams
2017-02-06 16:24     ` Dan Williams
2017-02-06 16:24     ` Dan Williams
2017-02-06 17:27     ` Christoph Hellwig
2017-02-06 17:27       ` Christoph Hellwig
2017-02-06 17:27       ` Christoph Hellwig
2017-02-06 17:30       ` Dan Williams
2017-02-06 17:30         ` Dan Williams
2017-02-06 17:30         ` Dan Williams
2017-02-07  8:44         ` Kirill A. Shutemov [this message]
2017-02-07  8:44           ` Kirill A. Shutemov
2017-02-07  8:44           ` Kirill A. Shutemov
2017-02-07 16:56           ` Dan Williams
2017-02-07 16:56             ` Dan Williams
2017-02-07 16:56             ` Dan Williams
2017-02-07 17:40             ` Kirill A. Shutemov
2017-02-07 17:40               ` Kirill A. Shutemov
2017-02-07 17:40               ` Kirill A. Shutemov
2017-02-07 18:08               ` Dan Williams
2017-02-07 18:08                 ` Dan Williams
2017-02-07 18:08                 ` Dan Williams
2017-02-07 18:08                 ` Dan Williams
2017-02-08  8:41             ` Jan Kara
2017-02-08  8:41               ` Jan Kara
2017-02-08  8:41               ` Jan Kara
2017-02-08  8:41               ` Jan Kara

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=20170207084411.GA527@node.shutemov.name \
    --to=kirill@shutemov.name \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mawilcox@microsoft.com \
    --cc=vbabka@suse.cz \
    /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.