| Message ID | 20210714193542.21857-1-joao.m.martins@oracle.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mm, sparse-vmemmap: Introduce compound pagemaps | expand |
On Wed, 14 Jul 2021 20:35:28 +0100 Joao Martins <joao.m.martins@oracle.com> wrote: > This series, attempts at minimizing 'struct page' overhead by > pursuing a similar approach as Muchun Song series "Free some vmemmap > pages of hugetlb page"[0] but applied to devmap/ZONE_DEVICE which is now > in mmotm. > > [0] https://lore.kernel.org/linux-mm/20210308102807.59745-1-songmuchun@bytedance.com/ [0] is now in mainline. This patch series looks like it'll clash significantly with the folio work and it is pretty thinly reviewed, so I think I'll take a pass for now. Matthew, thoughts?
On Wed, Jul 14, 2021 at 2:48 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Wed, 14 Jul 2021 20:35:28 +0100 Joao Martins <joao.m.martins@oracle.com> wrote: > > > This series, attempts at minimizing 'struct page' overhead by > > pursuing a similar approach as Muchun Song series "Free some vmemmap > > pages of hugetlb page"[0] but applied to devmap/ZONE_DEVICE which is now > > in mmotm. > > > > [0] https://lore.kernel.org/linux-mm/20210308102807.59745-1-songmuchun@bytedance.com/ > > [0] is now in mainline. > > This patch series looks like it'll clash significantly with the folio > work and it is pretty thinly reviewed, Sorry about that, I've promised Joao some final reviewed-by tags and testing for a while, and the gears are turning now. > so I think I'll take a pass for now. Matthew, thoughts? I'll defer to Matthew about folio collision, but I did not think this compound page geometry setup for memremap_pages() would collide with folios that want to clarify passing multi-order pages around the kernel. Joao is solving a long standing criticism of memremap_pages() usage for PMEM where the page metadata is too large to fit in RAM and the page array in PMEM is noticeably slower to pin for frequent pin_user_pages() events. memremap_pages() is a good first candidate for this solution given it's pages never get handled by the page allocator. If anything it allows folios to seep deeper into the DAX code as it knocks down the "base-pages only" assumption of those paths.
On Wed, Jul 14, 2021 at 02:48:30PM -0700, Andrew Morton wrote: > On Wed, 14 Jul 2021 20:35:28 +0100 Joao Martins <joao.m.martins@oracle.com> wrote: > > > This series, attempts at minimizing 'struct page' overhead by > > pursuing a similar approach as Muchun Song series "Free some vmemmap > > pages of hugetlb page"[0] but applied to devmap/ZONE_DEVICE which is now > > in mmotm. > > > > [0] https://lore.kernel.org/linux-mm/20210308102807.59745-1-songmuchun@bytedance.com/ > > [0] is now in mainline. > > This patch series looks like it'll clash significantly with the folio > work and it is pretty thinly reviewed, so I think I'll take a pass for > now. Matthew, thoughts? I had a look through it, and I don't see anything that looks like it'll clash with the folio patches. The folio work really touches the page cache for now, and this seems mostly to touch the devmap paths. It would be nice to convert the devmap code to folios too, but that can wait. The mess with page refcounts needs to be sorted out first.
On 7/22/21 3:24 AM, Matthew Wilcox wrote: > On Wed, Jul 14, 2021 at 02:48:30PM -0700, Andrew Morton wrote: >> On Wed, 14 Jul 2021 20:35:28 +0100 Joao Martins <joao.m.martins@oracle.com> wrote: >> >>> This series, attempts at minimizing 'struct page' overhead by >>> pursuing a similar approach as Muchun Song series "Free some vmemmap >>> pages of hugetlb page"[0] but applied to devmap/ZONE_DEVICE which is now >>> in mmotm. >>> >>> [0] https://lore.kernel.org/linux-mm/20210308102807.59745-1-songmuchun@bytedance.com/ >> >> [0] is now in mainline. >> >> This patch series looks like it'll clash significantly with the folio >> work and it is pretty thinly reviewed, so I think I'll take a pass for >> now. Matthew, thoughts? > > I had a look through it, and I don't see anything that looks like it'll > clash with the folio patches. FWIW, I had tried this last week, and this series applies cleanly on top of your 130+ patch series for Folios. > The folio work really touches the page > cache for now, and this seems mostly to touch the devmap paths. > /me nods -- it really is about devmap infra for usage in device-dax for persistent memory. Perhaps I should do s/pagemaps/devmap/ throughout the series to avoid confusion. > It would be nice to convert the devmap code to folios too, but that > can wait. The mess with page refcounts needs to be sorted out first. > I suppose you refer to fixing the current zone-device elevated page ref count? https://lore.kernel.org/linux-mm/20210717192135.9030-3-alex.sierra@amd.com/
On Thu, Jul 22, 2021 at 3:54 AM Joao Martins <joao.m.martins@oracle.com> wrote: [..] > > The folio work really touches the page > > cache for now, and this seems mostly to touch the devmap paths. > > > /me nods -- it really is about devmap infra for usage in device-dax for persistent memory. > > Perhaps I should do s/pagemaps/devmap/ throughout the series to avoid confusion. I also like "devmap" as a more accurate name. It matches the PFN_DEV and PFN_MAP flags that decorate DAX capable pfn_t instances. It also happens to match a recommendation I gave to Ira for his support for supervisor protection keys with devmap pfns.
On 7/28/21 12:23 AM, Dan Williams wrote: > On Thu, Jul 22, 2021 at 3:54 AM Joao Martins <joao.m.martins@oracle.com> wrote: > [..] >>> The folio work really touches the page >>> cache for now, and this seems mostly to touch the devmap paths. >>> >> /me nods -- it really is about devmap infra for usage in device-dax for persistent memory. >> >> Perhaps I should do s/pagemaps/devmap/ throughout the series to avoid confusion. > > I also like "devmap" as a more accurate name. It matches the PFN_DEV > and PFN_MAP flags that decorate DAX capable pfn_t instances. It also > happens to match a recommendation I gave to Ira for his support for > supervisor protection keys with devmap pfns. > /me nods Additionally, I think I'll be reordering the patches for more clear/easier bisection i.e. first introducing compound pages for devmap, fixing associated issues wrt to the slow pinning and then introduce vmemmap deduplication for devmap. It should look like below after the reordering from first patch to last. Let me know if you disagree. memory-failure: fetch compound_head after pgmap_pfn_valid() mm/page_alloc: split prep_compound_page into head and tail subparts mm/page_alloc: refactor memmap_init_zone_device() page init mm/memremap: add ZONE_DEVICE support for compound pages device-dax: use ALIGN() for determining pgoff device-dax: compound devmap support mm/gup: grab head page refcount once for group of subpages mm/sparse-vmemmap: add a pgmap argument to section activation mm/sparse-vmemmap: refactor core of vmemmap_populate_basepages() to helper mm/hugetlb_vmemmap: move comment block to Documentation/vm mm/sparse-vmemmap: populate compound devmaps mm/page_alloc: reuse tail struct pages for compound devmaps mm/sparse-vmemmap: improve memory savings for compound pud geometry
On Mon, Aug 2, 2021 at 3:41 AM Joao Martins <joao.m.martins@oracle.com> wrote: > > > > On 7/28/21 12:23 AM, Dan Williams wrote: > > On Thu, Jul 22, 2021 at 3:54 AM Joao Martins <joao.m.martins@oracle.com> wrote: > > [..] > >>> The folio work really touches the page > >>> cache for now, and this seems mostly to touch the devmap paths. > >>> > >> /me nods -- it really is about devmap infra for usage in device-dax for persistent memory. > >> > >> Perhaps I should do s/pagemaps/devmap/ throughout the series to avoid confusion. > > > > I also like "devmap" as a more accurate name. It matches the PFN_DEV > > and PFN_MAP flags that decorate DAX capable pfn_t instances. It also > > happens to match a recommendation I gave to Ira for his support for > > supervisor protection keys with devmap pfns. > > > /me nods > > Additionally, I think I'll be reordering the patches for more clear/easier > bisection i.e. first introducing compound pages for devmap, fixing associated > issues wrt to the slow pinning and then introduce vmemmap deduplication for > devmap. > > It should look like below after the reordering from first patch to last. > Let me know if you disagree. > > memory-failure: fetch compound_head after pgmap_pfn_valid() > mm/page_alloc: split prep_compound_page into head and tail subparts > mm/page_alloc: refactor memmap_init_zone_device() page init > mm/memremap: add ZONE_DEVICE support for compound pages > device-dax: use ALIGN() for determining pgoff > device-dax: compound devmap support > mm/gup: grab head page refcount once for group of subpages > mm/sparse-vmemmap: add a pgmap argument to section activation > mm/sparse-vmemmap: refactor core of vmemmap_populate_basepages() to helper > mm/hugetlb_vmemmap: move comment block to Documentation/vm > mm/sparse-vmemmap: populate compound devmaps > mm/page_alloc: reuse tail struct pages for compound devmaps > mm/sparse-vmemmap: improve memory savings for compound pud geometry LGTM.
Changes since v2 [1]: * Collect Mike's Ack on patch 2 (Mike) * Collect Naoya's Reviewed-by on patch 1 (Naoya) * Rename compound_pagemaps.rst doc page (and its mentions) to vmemmap_dedup.rst (Mike, Muchun) * Rebased to next-20210714 Changes since v1 [0]: (New patches 7, 10, 11) * Remove occurences of 'we' in the commit descriptions (now for real) [Dan] * Add comment on top of compound_head() for fsdax (Patch 1) [Dan] * Massage commit descriptions of cleanup/refactor patches to reflect [Dan] that it's in preparation for bigger infra in sparse-vmemmap. (Patch 2,3,5) [Dan] * Greatly improve all commit messages in terms of grammar/wording and clearity. [Dan] * Rename variable/helpers from dev_pagemap::align to @geometry, reflecting tht it's not the same thing as dev_dax->align, Patch 4 [Dan] * Move compound page init logic into separate memmap_init_compound() helper, Patch 4 [Dan] * Simplify patch 9 as a result of having compound initialization differently [Dan] * Rename @pfn_align variable in memmap_init_zone_device to @pfns_per_compound [Dan] * Rename Subject of patch 6 [Dan] * Move hugetlb_vmemmap.c comment block to Documentation/vm Patch 7 [Dan] * Add some type-safety to @block and use 'struct page *' rather than void, Patch 8 [Dan] * Add some comments to less obvious parts on 1G compound page case, Patch 8 [Dan] * Remove vmemmap lookup function in place of pmd_off_k() + pte_offset_kernel() given some guarantees on section onlining serialization, Patch 8 * Add a comment to get_page() mentioning where/how it is, Patch 8 freed [Dan] * Add docs about device-dax usage of tail dedup technique in newly added compound_pagemaps.rst doc entry. * Add cleanup patch for device-dax for ensuring dev_dax::pgmap is always set [Dan] * Add cleanup patch for device-dax for using ALIGN() [Dan] * Store pinned head in separate @pinned_head variable and fix error case, patch 13 [Dan] * Add comment on difference of @next value for PageCompound(), patch 13 [Dan] * Move PUD compound page to be last patch [Dan] * Add vmemmap layout for PUD compound geometry in compound_pagemaps.rst doc, patch 14 [Dan] * Rebased to next-20210617 [0] https://lore.kernel.org/linux-mm/20210325230938.30752-1-joao.m.martins@oracle.com/ [1] https://lore.kernel.org/linux-mm/20210617184507.3662-1-joao.m.martins@oracle.com/ Full changelog of previous versions at the bottom of cover letter. --- This series, attempts at minimizing 'struct page' overhead by pursuing a similar approach as Muchun Song series "Free some vmemmap pages of hugetlb page"[0] but applied to devmap/ZONE_DEVICE which is now in mmotm. [0] https://lore.kernel.org/linux-mm/20210308102807.59745-1-songmuchun@bytedance.com/ The link above describes it quite nicely, but the idea is to reuse tail page vmemmap areas, particular the area which only describes tail pages. So a vmemmap page describes 64 struct pages, and the first page for a given ZONE_DEVICE vmemmap would contain the head page and 63 tail pages. The second vmemmap page would contain only tail pages, and that's what gets reused across the rest of the subsection/section. The bigger the page size, the bigger the savings (2M hpage -> save 6 vmemmap pages; 1G hpage -> save 4094 vmemmap pages). This series also takes one step further on 1GB pages and *also* reuse PMD pages which only contain tail pages which allows to keep parity with current hugepage based memmap. This further let us more than halve the overhead with 1GB pages (40M -> 16M per Tb) In terms of savings, per 1Tb of memory, the struct page cost would go down with compound pagemap: * with 2M pages we lose 4G instead of 16G (0.39% instead of 1.5% of total memory) * with 1G pages we lose 16MB instead of 16G (0.0014% instead of 1.5% of total memory) Along the way I've extended it past 'struct page' overhead *trying* to address a few performance issues we knew about for pmem, specifically on the {pin,get}_user_pages_fast with device-dax vmas which are really slow even of the fast variants. THP is great on -fast variants but all except hugetlbfs perform rather poorly on non-fast gup. Although I deferred the __get_user_pages() improvements (in a follow up series I have stashed as its ortogonal to device-dax as THP suffers from the same syndrome). So to summarize what the series does: Patch 1: Prepare hwpoisoning to work with dax compound pages. Patches 2-4: Have memmap_init_zone_device() initialize its metadata as compound pages. We split the current utility function of prep_compound_page() into head and tail and use those two helpers where appropriate to take advantage of caches being warm after __init_single_page(). Since RFC this also lets us further speed up from 190ms down to 80ms init time. Patches 5-12, 14: Much like Muchun series, we reuse PTE (and PMD) tail page vmemmap areas across a given page size (namely @align was referred by remaining memremap/dax code) and enabling of memremap to initialize the ZONE_DEVICE pages as compound pages or a given @align order. The main difference though, is that contrary to the hugetlbfs series, there's no vmemmap for the area, because we are populating it as opposed to remapping it. IOW no freeing of pages of already initialized vmemmap like the case for hugetlbfs, which simplifies the logic (besides not being arch-specific). After these, there's quite visible region bootstrap of pmem memmap given that we would initialize fewer struct pages depending on the page size with DRAM backed struct pages. altmap sees no difference in bootstrap. Patch 14 comes last as it's an improvement, not mandated for the initial functionality. Also move the very nice docs of hugetlb_vmemmap.c into a Documentation/vm/ entry. NVDIMM namespace bootstrap improves from ~268-358 ms to ~78-100/<1ms on 128G NVDIMMs with 2M and 1G respectivally. Patch 13: Optimize grabbing page refcount changes given that we are working with compound pages i.e. we do 1 increment to the head page for a given set of N subpages compared as opposed to N individual writes. {get,pin}_user_pages_fast() for zone_device with compound pagemap consequently improves considerably with DRAM stored struct pages. It also *greatly* improves pinning with altmap. Results with gup_test: before after (16G get_user_pages_fast 2M page size) ~59 ms -> ~6.1 ms (16G pin_user_pages_fast 2M page size) ~87 ms -> ~6.2 ms (16G get_user_pages_fast altmap 2M page size) ~494 ms -> ~9 ms (16G pin_user_pages_fast altmap 2M page size) ~494 ms -> ~10 ms altmap performance gets specially interesting when pinning a pmem dimm: before after (128G get_user_pages_fast 2M page size) ~492 ms -> ~49 ms (128G pin_user_pages_fast 2M page size) ~493 ms -> ~50 ms (128G get_user_pages_fast altmap 2M page size) ~3.91 s -> ~70 ms (128G pin_user_pages_fast altmap 2M page size) ~3.97 s -> ~74 ms I have deferred the __get_user_pages() patch to outside this series (https://lore.kernel.org/linux-mm/20201208172901.17384-11-joao.m.martins@oracle.com/), as I found an simpler way to address it and that is also applicable to THP. But will submit that as a follow up of this. Patches apply on top of linux-next tag next-20210714 (commit c0d438dbc0b7). Comments and suggestions very much appreciated! Older Changelog, RFC[1] -> v1: (New patches 1-3, 5-8 but the diffstat isn't that different) * Fix hwpoisoning of devmap pages reported by Jane (Patch 1 is new in v1) * Fix/Massage commit messages to be more clear and remove the 'we' occurences (Dan, John, Matthew) * Use pfn_align to be clear it's nr of pages for @align value (John, Dan) * Add two helpers pgmap_align() and pgmap_pfn_align() as accessors of pgmap->align; * Remove the gup_device_compound_huge special path and have the same code work both ways while special casing when devmap page is compound (Jason, John) * Avoid usage of vmemmap_populate_basepages() and introduce a first class loop that doesn't care about passing an altmap for memmap reuse. (Dan) * Completely rework the vmemmap_populate_compound() to avoid the sparse_add_section hack into passing block across sparse_add_section calls. It's a lot easier to follow and more explicit in what it does. * Replace the vmemmap refactoring with adding a @pgmap argument and moving parts of the vmemmap_populate_base_pages(). (Patch 5 and 6 are new as a result) * Add PMD tail page vmemmap area reuse for 1GB pages. (Patch 8 is new) * Improve memmap_init_zone_device() to initialize compound pages when struct pages are cache warm. That lead to a even further speed up further from RFC series from 190ms -> 80-120ms. Patches 2 and 3 are the new ones as a result (Dan) * Remove PGMAP_COMPOUND and use @align as the property to detect whether or not to reuse vmemmap areas (Dan) [1] https://lore.kernel.org/linux-mm/20201208172901.17384-1-joao.m.martins@oracle.com/ Thanks, Joao Joao Martins (14): memory-failure: fetch compound_head after pgmap_pfn_valid() mm/page_alloc: split prep_compound_page into head and tail subparts mm/page_alloc: refactor memmap_init_zone_device() page init mm/memremap: add ZONE_DEVICE support for compound pages mm/sparse-vmemmap: add a pgmap argument to section activation mm/sparse-vmemmap: refactor core of vmemmap_populate_basepages() to helper mm/hugetlb_vmemmap: move comment block to Documentation/vm mm/sparse-vmemmap: populate compound pagemaps mm/page_alloc: reuse tail struct pages for compound pagemaps device-dax: use ALIGN() for determining pgoff device-dax: ensure dev_dax->pgmap is valid for dynamic devices device-dax: compound pagemap support mm/gup: grab head page refcount once for group of subpages mm/sparse-vmemmap: improve memory savings for compound pud geometry Documentation/vm/index.rst | 1 + Documentation/vm/vmemmap_dedup.rst | 300 +++++++++++++++++++++++++++++ drivers/dax/device.c | 58 ++++-- include/linux/memory_hotplug.h | 5 +- include/linux/memremap.h | 17 ++ include/linux/mm.h | 8 +- mm/gup.c | 53 +++-- mm/hugetlb_vmemmap.c | 162 +--------------- mm/memory-failure.c | 6 + mm/memory_hotplug.c | 3 +- mm/memremap.c | 9 +- mm/page_alloc.c | 146 ++++++++++---- mm/sparse-vmemmap.c | 226 +++++++++++++++++++--- mm/sparse.c | 24 ++- 14 files changed, 742 insertions(+), 276 deletions(-) create mode 100644 Documentation/vm/vmemmap_dedup.rst