From: Joao Martins <joao.m.martins@oracle.com> To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>, Dan Williams <dan.j.williams@intel.com> Cc: Linux MM <linux-mm@kvack.org>, Ira Weiny <ira.weiny@intel.com>, linux-nvdimm <linux-nvdimm@lists.01.org>, Matthew Wilcox <willy@infradead.org>, Jason Gunthorpe <jgg@ziepe.ca>, Jane Chu <jane.chu@oracle.com>, Muchun Song <songmuchun@bytedance.com>, Mike Kravetz <mike.kravetz@oracle.com>, Andrew Morton <akpm@linux-foundation.org> Subject: Re: [PATCH v1 04/11] mm/memremap: add ZONE_DEVICE support for compound pages Date: Thu, 6 May 2021 11:23:25 +0100 [thread overview] Message-ID: <31563092-a7b8-e6e1-f5ad-a66c02243a9d@oracle.com> (raw) In-Reply-To: <87zgx85ltc.fsf@linux.ibm.com> On 5/6/21 9:05 AM, Aneesh Kumar K.V wrote: > > > IIUC this series is about devdax namespace with aligh of 1G or 2M where we can > save the vmmemap space by not allocating memory for tail struct pages? > Right. It reuses base pages across the vmemmap, but for the base pages containing only the tail struct pages. > Dan Williams <dan.j.williams@intel.com> writes: > >>> enum: >>>> >>>> enum devmap_geometry { >>>> DEVMAP_PTE, >>>> DEVMAP_PMD, >>>> DEVMAP_PUD, >>>> } >>>> >>> I suppose a converter between devmap_geometry and page_size would be needed too? And maybe >>> the whole dax/nvdimm align values change meanwhile (as a followup improvement)? >> >> I think it is ok for dax/nvdimm to continue to maintain their align >> value because it should be ok to have 4MB align if the device really >> wanted. However, when it goes to map that alignment with >> memremap_pages() it can pick a mode. For example, it's already the >> case that dax->align == 1GB is mapped with DEVMAP_PTE today, so >> they're already separate concepts that can stay separate. > > devdax namespace with align of 1G implies we expect to map them with 1G > pte entries? I didn't follow when you say we map them today with > DEVMAP_PTE entries. > This sort of confusion is largelly why Dan is suggesting a @geometry for naming rather than @align (which traditionally refers to page tables entry sizes in pagemap-related stuff). DEVMAP_{PTE,PMD,PUD} refers to the representation of metadata in base pages (DEVMAP_PTE), compound pages of PMD order (DEVMAP_PMD) or compound pages of PUD order (DEVMAP_PUD). So, today: * namespaces with align of 1G would use *struct pages of order-0* (DEVMAP_PTE) backed with PMD entries in the direct map. * namespaces with align of 2M would use *struct pages of order-0* (DEVMAP_PTE) backed with PMD entries in the direct map. After this series: * namespaces with align of 1G would use *compound struct pages of order-30* (DEVMAP_PUD) backed with PMD entries in the direct map. * namespaces with align of 1G would use *compound struct pages of order-21* (DEVMAP_PMD) backed with PTE entries in the direct map.
WARNING: multiple messages have this Message-ID (diff)
From: Joao Martins <joao.m.martins@oracle.com> To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>, Dan Williams <dan.j.williams@intel.com> Cc: Linux MM <linux-mm@kvack.org>, linux-nvdimm <linux-nvdimm@lists.01.org>, Matthew Wilcox <willy@infradead.org>, Jason Gunthorpe <jgg@ziepe.ca>, Jane Chu <jane.chu@oracle.com>, Muchun Song <songmuchun@bytedance.com>, Mike Kravetz <mike.kravetz@oracle.com>, Andrew Morton <akpm@linux-foundation.org> Subject: Re: [PATCH v1 04/11] mm/memremap: add ZONE_DEVICE support for compound pages Date: Thu, 6 May 2021 11:23:25 +0100 [thread overview] Message-ID: <31563092-a7b8-e6e1-f5ad-a66c02243a9d@oracle.com> (raw) In-Reply-To: <87zgx85ltc.fsf@linux.ibm.com> On 5/6/21 9:05 AM, Aneesh Kumar K.V wrote: > > > IIUC this series is about devdax namespace with aligh of 1G or 2M where we can > save the vmmemap space by not allocating memory for tail struct pages? > Right. It reuses base pages across the vmemmap, but for the base pages containing only the tail struct pages. > Dan Williams <dan.j.williams@intel.com> writes: > >>> enum: >>>> >>>> enum devmap_geometry { >>>> DEVMAP_PTE, >>>> DEVMAP_PMD, >>>> DEVMAP_PUD, >>>> } >>>> >>> I suppose a converter between devmap_geometry and page_size would be needed too? And maybe >>> the whole dax/nvdimm align values change meanwhile (as a followup improvement)? >> >> I think it is ok for dax/nvdimm to continue to maintain their align >> value because it should be ok to have 4MB align if the device really >> wanted. However, when it goes to map that alignment with >> memremap_pages() it can pick a mode. For example, it's already the >> case that dax->align == 1GB is mapped with DEVMAP_PTE today, so >> they're already separate concepts that can stay separate. > > devdax namespace with align of 1G implies we expect to map them with 1G > pte entries? I didn't follow when you say we map them today with > DEVMAP_PTE entries. > This sort of confusion is largelly why Dan is suggesting a @geometry for naming rather than @align (which traditionally refers to page tables entry sizes in pagemap-related stuff). DEVMAP_{PTE,PMD,PUD} refers to the representation of metadata in base pages (DEVMAP_PTE), compound pages of PMD order (DEVMAP_PMD) or compound pages of PUD order (DEVMAP_PUD). So, today: * namespaces with align of 1G would use *struct pages of order-0* (DEVMAP_PTE) backed with PMD entries in the direct map. * namespaces with align of 2M would use *struct pages of order-0* (DEVMAP_PTE) backed with PMD entries in the direct map. After this series: * namespaces with align of 1G would use *compound struct pages of order-30* (DEVMAP_PUD) backed with PMD entries in the direct map. * namespaces with align of 1G would use *compound struct pages of order-21* (DEVMAP_PMD) backed with PTE entries in the direct map. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
next prev parent reply other threads:[~2021-05-06 10:23 UTC|newest] Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-25 23:09 [PATCH v1 00/11] mm, sparse-vmemmap: Introduce compound pagemaps Joao Martins 2021-03-25 23:09 ` Joao Martins 2021-03-25 23:09 ` [PATCH v1 01/11] memory-failure: fetch compound_head after pgmap_pfn_valid() Joao Martins 2021-03-25 23:09 ` Joao Martins 2021-04-24 0:12 ` Dan Williams 2021-04-24 0:12 ` Dan Williams 2021-04-24 19:00 ` Joao Martins 2021-04-24 19:00 ` Joao Martins 2021-03-25 23:09 ` [PATCH v1 02/11] mm/page_alloc: split prep_compound_page into head and tail subparts Joao Martins 2021-03-25 23:09 ` Joao Martins 2021-04-24 0:16 ` Dan Williams 2021-04-24 0:16 ` Dan Williams 2021-04-24 19:05 ` Joao Martins 2021-04-24 19:05 ` Joao Martins 2021-03-25 23:09 ` [PATCH v1 03/11] mm/page_alloc: refactor memmap_init_zone_device() page init Joao Martins 2021-03-25 23:09 ` Joao Martins 2021-04-24 0:18 ` Dan Williams 2021-04-24 0:18 ` Dan Williams 2021-04-24 19:05 ` Joao Martins 2021-04-24 19:05 ` Joao Martins 2021-03-25 23:09 ` [PATCH v1 04/11] mm/memremap: add ZONE_DEVICE support for compound pages Joao Martins 2021-03-25 23:09 ` Joao Martins 2021-05-05 18:44 ` Dan Williams 2021-05-05 18:44 ` Dan Williams 2021-05-05 18:58 ` Matthew Wilcox 2021-05-05 18:58 ` Matthew Wilcox 2021-05-05 19:49 ` Joao Martins 2021-05-05 19:49 ` Joao Martins 2021-05-05 22:20 ` Dan Williams 2021-05-05 22:20 ` Dan Williams 2021-05-05 22:36 ` Joao Martins 2021-05-05 22:36 ` Joao Martins 2021-05-05 23:03 ` Dan Williams 2021-05-05 23:03 ` Dan Williams 2021-05-06 10:12 ` Joao Martins 2021-05-06 10:12 ` Joao Martins 2021-05-18 17:27 ` Joao Martins 2021-05-18 17:27 ` Joao Martins 2021-05-18 19:56 ` Jane Chu 2021-05-18 19:56 ` Jane Chu 2021-05-19 11:29 ` Joao Martins 2021-05-19 11:29 ` Joao Martins 2021-05-19 18:36 ` Jane Chu 2021-06-07 20:17 ` Dan Williams 2021-06-07 20:47 ` Joao Martins 2021-06-07 21:00 ` Joao Martins 2021-06-07 21:57 ` Dan Williams 2021-05-06 8:05 ` Aneesh Kumar K.V 2021-05-06 8:05 ` Aneesh Kumar K.V 2021-05-06 10:23 ` Joao Martins [this message] 2021-05-06 10:23 ` Joao Martins 2021-05-06 11:43 ` Matthew Wilcox 2021-05-06 11:43 ` Matthew Wilcox 2021-05-06 12:15 ` Joao Martins 2021-05-06 12:15 ` Joao Martins 2021-03-25 23:09 ` [PATCH v1 05/11] mm/sparse-vmemmap: add a pgmap argument to section activation Joao Martins 2021-03-25 23:09 ` Joao Martins 2021-05-05 22:34 ` Dan Williams 2021-05-05 22:34 ` Dan Williams 2021-05-05 22:37 ` Joao Martins 2021-05-05 22:37 ` Joao Martins 2021-05-05 23:14 ` Dan Williams 2021-05-05 23:14 ` Dan Williams 2021-05-06 10:24 ` Joao Martins 2021-05-06 10:24 ` Joao Martins 2021-03-25 23:09 ` [PATCH v1 06/11] mm/sparse-vmemmap: refactor vmemmap_populate_basepages() Joao Martins 2021-03-25 23:09 ` Joao Martins 2021-05-05 22:43 ` Dan Williams 2021-05-05 22:43 ` Dan Williams 2021-05-06 10:27 ` Joao Martins 2021-05-06 10:27 ` Joao Martins 2021-05-06 18:36 ` Joao Martins 2021-05-06 18:36 ` Joao Martins 2021-03-25 23:09 ` [PATCH v1 07/11] mm/sparse-vmemmap: populate compound pagemaps Joao Martins 2021-03-25 23:09 ` Joao Martins 2021-05-06 1:18 ` Dan Williams 2021-05-06 1:18 ` Dan Williams 2021-05-06 11:01 ` Joao Martins 2021-05-06 11:01 ` Joao Martins 2021-05-10 19:19 ` Dan Williams 2021-05-10 19:19 ` Dan Williams 2021-05-13 18:45 ` Joao Martins 2021-05-13 18:45 ` Joao Martins 2021-06-16 15:05 ` Joao Martins 2021-06-16 23:35 ` Dan Williams 2021-03-25 23:09 ` [PATCH v1 08/11] mm/sparse-vmemmap: use hugepages for PUD " Joao Martins 2021-03-25 23:09 ` Joao Martins 2021-06-01 19:30 ` Dan Williams 2021-06-07 12:02 ` Joao Martins 2021-06-07 19:47 ` Dan Williams 2021-03-25 23:09 ` [PATCH v1 09/11] mm/page_alloc: reuse tail struct pages for " Joao Martins 2021-03-25 23:09 ` Joao Martins 2021-06-01 23:35 ` Dan Williams 2021-06-07 13:48 ` Joao Martins 2021-06-07 19:32 ` Dan Williams 2021-06-14 18:41 ` Joao Martins 2021-06-14 23:07 ` Dan Williams 2021-03-25 23:09 ` [PATCH v1 10/11] device-dax: compound pagemap support Joao Martins 2021-03-25 23:09 ` Joao Martins 2021-06-02 0:36 ` Dan Williams 2021-06-07 13:59 ` Joao Martins 2021-03-25 23:09 ` [PATCH v1 11/11] mm/gup: grab head page refcount once for group of subpages Joao Martins 2021-03-25 23:09 ` Joao Martins 2021-06-02 1:05 ` Dan Williams 2021-06-07 15:21 ` Joao Martins 2021-06-07 19:22 ` Dan Williams 2021-04-01 9:38 ` [PATCH v1 00/11] mm, sparse-vmemmap: Introduce compound pagemaps Joao Martins 2021-04-01 9:38 ` Joao Martins
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=31563092-a7b8-e6e1-f5ad-a66c02243a9d@oracle.com \ --to=joao.m.martins@oracle.com \ --cc=akpm@linux-foundation.org \ --cc=aneesh.kumar@linux.ibm.com \ --cc=dan.j.williams@intel.com \ --cc=ira.weiny@intel.com \ --cc=jane.chu@oracle.com \ --cc=jgg@ziepe.ca \ --cc=linux-mm@kvack.org \ --cc=linux-nvdimm@lists.01.org \ --cc=mike.kravetz@oracle.com \ --cc=songmuchun@bytedance.com \ --cc=willy@infradead.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: linkBe 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.