On Wed, Jul 14, 2021 at 2:48 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 14 Jul 2021 20:35:28 +0100 Joao Martins <joao.m.martins@xxxxxxxxxx> 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@xxxxxxxxxxxxx/ > > [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.
