From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Jan Kara <jack@suse.cz>, linux-nvdimm <linux-nvdimm@lists.01.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>, Ross Zwisler <zwisler@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH 2/2] mm/dax: Don't enable huge dax mapping by default
Date: Wed, 20 Mar 2019 13:36:43 +0530 [thread overview]
Message-ID: <87bm267ywc.fsf@linux.ibm.com> (raw)
In-Reply-To: <CAPcyv4i0SahDP=_ZQV3RG_b5pMkjn-9Cjy7OpY2sm1PxLdO8jA@mail.gmail.com>
Dan Williams <dan.j.williams@intel.com> writes:
>
>> Now what will be page size used for mapping vmemmap?
>
> That's up to the architecture's vmemmap_populate() implementation.
>
>> Architectures
>> possibly will use PMD_SIZE mapping if supported for vmemmap. Now a
>> device-dax with struct page in the device will have pfn reserve area aligned
>> to PAGE_SIZE with the above example? We can't map that using
>> PMD_SIZE page size?
>
> IIUC, that's a different alignment. Currently that's handled by
> padding the reservation area up to a section (128MB on x86) boundary,
> but I'm working on patches to allow sub-section sized ranges to be
> mapped.
I am missing something w.r.t code. The below code align that using nd_pfn->align
if (nd_pfn->mode == PFN_MODE_PMEM) {
unsigned long memmap_size;
/*
* vmemmap_populate_hugepages() allocates the memmap array in
* HPAGE_SIZE chunks.
*/
memmap_size = ALIGN(64 * npfns, HPAGE_SIZE);
offset = ALIGN(start + SZ_8K + memmap_size + dax_label_reserve,
nd_pfn->align) - start;
}
IIUC that is finding the offset where to put vmemmap start. And that has
to be aligned to the page size with which we may end up mapping vmemmap
area right?
Yes we find the npfns by aligning up using PAGES_PER_SECTION. But that
is to compute howmany pfns we should map for this pfn dev right?
-aneesh
_______________________________________________
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: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Jan Kara <jack@suse.cz>, linux-nvdimm <linux-nvdimm@lists.01.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>, Ross Zwisler <zwisler@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH 2/2] mm/dax: Don't enable huge dax mapping by default
Date: Wed, 20 Mar 2019 13:36:43 +0530 [thread overview]
Message-ID: <87bm267ywc.fsf@linux.ibm.com> (raw)
In-Reply-To: <CAPcyv4i0SahDP=_ZQV3RG_b5pMkjn-9Cjy7OpY2sm1PxLdO8jA@mail.gmail.com>
Dan Williams <dan.j.williams@intel.com> writes:
>
>> Now what will be page size used for mapping vmemmap?
>
> That's up to the architecture's vmemmap_populate() implementation.
>
>> Architectures
>> possibly will use PMD_SIZE mapping if supported for vmemmap. Now a
>> device-dax with struct page in the device will have pfn reserve area aligned
>> to PAGE_SIZE with the above example? We can't map that using
>> PMD_SIZE page size?
>
> IIUC, that's a different alignment. Currently that's handled by
> padding the reservation area up to a section (128MB on x86) boundary,
> but I'm working on patches to allow sub-section sized ranges to be
> mapped.
I am missing something w.r.t code. The below code align that using nd_pfn->align
if (nd_pfn->mode == PFN_MODE_PMEM) {
unsigned long memmap_size;
/*
* vmemmap_populate_hugepages() allocates the memmap array in
* HPAGE_SIZE chunks.
*/
memmap_size = ALIGN(64 * npfns, HPAGE_SIZE);
offset = ALIGN(start + SZ_8K + memmap_size + dax_label_reserve,
nd_pfn->align) - start;
}
IIUC that is finding the offset where to put vmemmap start. And that has
to be aligned to the page size with which we may end up mapping vmemmap
area right?
Yes we find the npfns by aligning up using PAGES_PER_SECTION. But that
is to compute howmany pfns we should map for this pfn dev right?
-aneesh
WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Jan Kara <jack@suse.cz>, linux-nvdimm <linux-nvdimm@lists.01.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>, Ross Zwisler <zwisler@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH 2/2] mm/dax: Don't enable huge dax mapping by default
Date: Wed, 20 Mar 2019 13:36:43 +0530 [thread overview]
Message-ID: <87bm267ywc.fsf@linux.ibm.com> (raw)
In-Reply-To: <CAPcyv4i0SahDP=_ZQV3RG_b5pMkjn-9Cjy7OpY2sm1PxLdO8jA@mail.gmail.com>
Dan Williams <dan.j.williams@intel.com> writes:
>
>> Now what will be page size used for mapping vmemmap?
>
> That's up to the architecture's vmemmap_populate() implementation.
>
>> Architectures
>> possibly will use PMD_SIZE mapping if supported for vmemmap. Now a
>> device-dax with struct page in the device will have pfn reserve area aligned
>> to PAGE_SIZE with the above example? We can't map that using
>> PMD_SIZE page size?
>
> IIUC, that's a different alignment. Currently that's handled by
> padding the reservation area up to a section (128MB on x86) boundary,
> but I'm working on patches to allow sub-section sized ranges to be
> mapped.
I am missing something w.r.t code. The below code align that using nd_pfn->align
if (nd_pfn->mode == PFN_MODE_PMEM) {
unsigned long memmap_size;
/*
* vmemmap_populate_hugepages() allocates the memmap array in
* HPAGE_SIZE chunks.
*/
memmap_size = ALIGN(64 * npfns, HPAGE_SIZE);
offset = ALIGN(start + SZ_8K + memmap_size + dax_label_reserve,
nd_pfn->align) - start;
}
IIUC that is finding the offset where to put vmemmap start. And that has
to be aligned to the page size with which we may end up mapping vmemmap
area right?
Yes we find the npfns by aligning up using PAGES_PER_SECTION. But that
is to compute howmany pfns we should map for this pfn dev right?
-aneesh
next prev parent reply other threads:[~2019-03-20 8:06 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-28 8:35 [PATCH 1/2] fs/dax: deposit pagetable even when installing zero page Aneesh Kumar K.V
2019-02-28 8:35 ` Aneesh Kumar K.V
2019-02-28 8:35 ` [PATCH 2/2] mm/dax: Don't enable huge dax mapping by default Aneesh Kumar K.V
2019-02-28 8:35 ` Aneesh Kumar K.V
2019-02-28 9:40 ` Jan Kara
2019-02-28 9:40 ` Jan Kara
2019-02-28 12:32 ` Aneesh Kumar K.V
2019-02-28 12:32 ` Aneesh Kumar K.V
2019-02-28 9:40 ` Oliver
2019-02-28 9:40 ` Oliver
2019-02-28 12:43 ` Aneesh Kumar K.V
2019-02-28 12:43 ` Aneesh Kumar K.V
2019-02-28 16:45 ` Dan Williams
2019-02-28 16:45 ` Dan Williams
2019-03-06 9:17 ` Aneesh Kumar K.V
2019-03-06 9:17 ` Aneesh Kumar K.V
2019-03-06 9:17 ` Aneesh Kumar K.V
2019-03-06 11:44 ` Michal Suchánek
2019-03-06 11:44 ` Michal Suchánek
2019-03-06 11:44 ` Michal Suchánek
2019-03-06 12:45 ` Aneesh Kumar K.V
2019-03-06 12:45 ` Aneesh Kumar K.V
2019-03-06 13:06 ` Kirill A. Shutemov
2019-03-06 13:06 ` Kirill A. Shutemov
2019-03-06 13:06 ` Kirill A. Shutemov
2019-03-13 16:07 ` Dan Williams
2019-03-13 16:07 ` Dan Williams
2019-03-13 16:07 ` Dan Williams
2019-03-19 8:44 ` Kirill A. Shutemov
2019-03-19 8:44 ` Kirill A. Shutemov
2019-03-19 8:44 ` Kirill A. Shutemov
2019-03-19 15:36 ` Dan Williams
2019-03-19 15:36 ` Dan Williams
2019-03-19 15:36 ` Dan Williams
2019-03-13 16:02 ` Dan Williams
2019-03-13 16:02 ` Dan Williams
2019-03-13 16:02 ` Dan Williams
2019-03-14 3:45 ` Aneesh Kumar K.V
2019-03-14 3:45 ` Aneesh Kumar K.V
2019-03-14 3:45 ` Aneesh Kumar K.V
2019-03-14 4:02 ` Dan Williams
2019-03-14 4:02 ` Dan Williams
2019-03-14 4:02 ` Dan Williams
2019-03-20 8:06 ` Aneesh Kumar K.V [this message]
2019-03-20 8:06 ` Aneesh Kumar K.V
2019-03-20 8:06 ` Aneesh Kumar K.V
2019-03-20 8:09 ` Aneesh Kumar K.V
2019-03-20 8:09 ` Aneesh Kumar K.V
2019-03-20 15:34 ` Dan Williams
2019-03-20 15:34 ` Dan Williams
2019-03-20 15:34 ` Dan Williams
2019-03-20 20:57 ` Dan Williams
2019-03-20 20:57 ` Dan Williams
2019-03-20 20:57 ` Dan Williams
2019-03-21 3:08 ` Oliver
2019-03-21 3:08 ` Oliver
2019-03-21 3:08 ` Oliver
2019-03-21 3:12 ` Dan Williams
2019-03-21 3:12 ` Dan Williams
2019-03-21 3:12 ` Dan Williams
2019-02-28 9:21 ` [PATCH 1/2] fs/dax: deposit pagetable even when installing zero page Jan Kara
2019-02-28 9:21 ` Jan Kara
2019-02-28 12:34 ` Aneesh Kumar K.V
2019-02-28 12:34 ` Aneesh Kumar K.V
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=87bm267ywc.fsf@linux.ibm.com \
--to=aneesh.kumar@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=jack@suse.cz \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=zwisler@kernel.org \
/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.