On Mon, Aug 2, 2021 at 3:41 AM Joao Martins <joao.m.martins@xxxxxxxxxx> 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@xxxxxxxxxx> 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.
