From: Toshi Kani <toshi.kani@hpe.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Matthew Wilcox <willy@linux.intel.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
mauricio.porto@hpe.com, Linux MM <linux-mm@kvack.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: Fix mmap MAP_POPULATE for DAX pmd mapping
Date: Wed, 02 Dec 2015 17:21:45 -0700 [thread overview]
Message-ID: <1449102105.9855.15.camel@hpe.com> (raw)
In-Reply-To: <1449078237.31589.30.camel@hpe.com>
On Wed, 2015-12-02 at 10:43 -0700, Toshi Kani wrote:
> On Tue, 2015-12-01 at 19:45 -0800, Dan Williams wrote:
> > On Tue, Dec 1, 2015 at 6:19 PM, Toshi Kani <toshi.kani@hpe.com> wrote:
> > > On Mon, 2015-11-30 at 14:08 -0800, Dan Williams wrote:
:
> > > >
> > > > Hey Toshi,
> > > >
> > > > I ended up fixing this differently with follow_pmd_devmap() introduced
> > > > in this series:
> > > >
> > > > https://lists.01.org/pipermail/linux-nvdimm/2015-November/003033.html
> > > >
> > > > Does the latest libnvdimm-pending branch [1] pass your test case?
> > >
> > > Hi Dan,
> > >
> > > I ran several test cases, and they all hit the case "pfn not in memmap" in
> > > __dax_pmd_fault() during mmap(MAP_POPULATE). Looking at the dax.pfn,
> > > PFN_DEV is set but PFN_MAP is not. I have not looked into why, but I
> > > thought I let you know first. I've also seen the test thread got hung up
> > > at the end sometime.
> >
> > That PFN_MAP flag will not be set by default for NFIT-defined
> > persistent memory. See pmem_should_map_pages() for pmem namespaces
> > that will have it set by default, currently only e820 type-12 memory
> > ranges.
> >
> > NFIT-defined persistent memory can have a memmap array dynamically
> > allocated by setting up a pfn device (similar to setting up a btt).
> > We don't map it by default because the NFIT may describe hundreds of
> > gigabytes of persistent and the overhead of the memmap may be too
> > large to locate the memmap in ram.
>
> Oh, I see. I will setup the memmap array and run the tests again.
I setup a pfn device, and ran a few test cases again. Yes, it solved the
PFN_MAP issue. However, I am no longer able to allocate FS blocks aligned by
2MB, so PMD faults fall back to PTE. They are off by 2 pages, which I suspect
due to the pfn metadata. If I pass a 2MB-aligned+2pages virtual address to
mmap(MAP_POPULATE), the mmap() call gets hung up.
Thanks,
-Toshi
--
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: Toshi Kani <toshi.kani@hpe.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Matthew Wilcox <willy@linux.intel.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
mauricio.porto@hpe.com, Linux MM <linux-mm@kvack.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: Fix mmap MAP_POPULATE for DAX pmd mapping
Date: Wed, 02 Dec 2015 17:21:45 -0700 [thread overview]
Message-ID: <1449102105.9855.15.camel@hpe.com> (raw)
In-Reply-To: <1449078237.31589.30.camel@hpe.com>
On Wed, 2015-12-02 at 10:43 -0700, Toshi Kani wrote:
> On Tue, 2015-12-01 at 19:45 -0800, Dan Williams wrote:
> > On Tue, Dec 1, 2015 at 6:19 PM, Toshi Kani <toshi.kani@hpe.com> wrote:
> > > On Mon, 2015-11-30 at 14:08 -0800, Dan Williams wrote:
:
> > > >
> > > > Hey Toshi,
> > > >
> > > > I ended up fixing this differently with follow_pmd_devmap() introduced
> > > > in this series:
> > > >
> > > > https://lists.01.org/pipermail/linux-nvdimm/2015-November/003033.html
> > > >
> > > > Does the latest libnvdimm-pending branch [1] pass your test case?
> > >
> > > Hi Dan,
> > >
> > > I ran several test cases, and they all hit the case "pfn not in memmap" in
> > > __dax_pmd_fault() during mmap(MAP_POPULATE). Looking at the dax.pfn,
> > > PFN_DEV is set but PFN_MAP is not. I have not looked into why, but I
> > > thought I let you know first. I've also seen the test thread got hung up
> > > at the end sometime.
> >
> > That PFN_MAP flag will not be set by default for NFIT-defined
> > persistent memory. See pmem_should_map_pages() for pmem namespaces
> > that will have it set by default, currently only e820 type-12 memory
> > ranges.
> >
> > NFIT-defined persistent memory can have a memmap array dynamically
> > allocated by setting up a pfn device (similar to setting up a btt).
> > We don't map it by default because the NFIT may describe hundreds of
> > gigabytes of persistent and the overhead of the memmap may be too
> > large to locate the memmap in ram.
>
> Oh, I see. I will setup the memmap array and run the tests again.
I setup a pfn device, and ran a few test cases again. Yes, it solved the
PFN_MAP issue. However, I am no longer able to allocate FS blocks aligned by
2MB, so PMD faults fall back to PTE. They are off by 2 pages, which I suspect
due to the pfn metadata. If I pass a 2MB-aligned+2pages virtual address to
mmap(MAP_POPULATE), the mmap() call gets hung up.
Thanks,
-Toshi
next prev parent reply other threads:[~2015-12-03 0:21 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-23 20:04 [PATCH] mm: Fix mmap MAP_POPULATE for DAX pmd mapping Toshi Kani
2015-11-23 20:04 ` Toshi Kani
2015-11-23 20:53 ` Dan Williams
2015-11-23 20:53 ` Dan Williams
2015-11-23 22:15 ` Toshi Kani
2015-11-23 22:15 ` Toshi Kani
2015-11-30 22:08 ` Dan Williams
2015-11-30 22:08 ` Dan Williams
2015-12-02 2:19 ` Toshi Kani
2015-12-02 2:19 ` Toshi Kani
2015-12-02 3:45 ` Dan Williams
2015-12-02 3:45 ` Dan Williams
2015-12-02 17:43 ` Toshi Kani
2015-12-02 17:43 ` Toshi Kani
2015-12-02 17:01 ` Dan Williams
2015-12-02 17:01 ` Dan Williams
2015-12-02 18:06 ` Dan Williams
2015-12-02 18:06 ` Dan Williams
2015-12-02 19:26 ` Toshi Kani
2015-12-02 19:26 ` Toshi Kani
2015-12-02 19:00 ` Dan Williams
2015-12-02 19:00 ` Dan Williams
2015-12-02 20:02 ` Toshi Kani
2015-12-02 20:02 ` Toshi Kani
2015-12-02 20:12 ` Toshi Kani
2015-12-02 20:12 ` Toshi Kani
2015-12-02 19:57 ` Dan Williams
2015-12-02 19:57 ` Dan Williams
2015-12-02 21:37 ` Toshi Kani
2015-12-02 21:37 ` Toshi Kani
2015-12-02 20:54 ` Dan Williams
2015-12-02 20:54 ` Dan Williams
2015-12-02 21:55 ` Toshi Kani
2015-12-02 21:55 ` Toshi Kani
2015-12-03 23:43 ` Dan Williams
2015-12-03 23:43 ` Dan Williams
2015-12-04 16:55 ` Toshi Kani
2015-12-04 16:55 ` Toshi Kani
2015-12-02 22:00 ` Dave Hansen
2015-12-02 22:00 ` Dave Hansen
2015-12-02 22:03 ` Dan Williams
2015-12-02 22:03 ` Dan Williams
2015-12-02 22:09 ` Dave Hansen
2015-12-02 22:09 ` Dave Hansen
2015-12-03 0:21 ` Toshi Kani [this message]
2015-12-03 0:21 ` Toshi Kani
2015-12-02 23:33 ` Dan Williams
2015-12-02 23:33 ` Dan Williams
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=1449102105.9855.15.camel@hpe.com \
--to=toshi.kani@hpe.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=mauricio.porto@hpe.com \
--cc=ross.zwisler@linux.intel.com \
--cc=willy@linux.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 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.