From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22D84C12002 for ; Wed, 14 Jul 2021 23:48:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A9020613B2 for ; Wed, 14 Jul 2021 23:48:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A9020613B2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CB1DF8D0008; Wed, 14 Jul 2021 19:48:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C615B8D0003; Wed, 14 Jul 2021 19:48:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B294D8D0008; Wed, 14 Jul 2021 19:48:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0063.hostedemail.com [216.40.44.63]) by kanga.kvack.org (Postfix) with ESMTP id 899E18D0003 for ; Wed, 14 Jul 2021 19:48:10 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 58B11180ACEE6 for ; Wed, 14 Jul 2021 23:48:09 +0000 (UTC) X-FDA: 78362834298.11.7BB3C60 Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) by imf15.hostedemail.com (Postfix) with ESMTP id F0128D0000B4 for ; Wed, 14 Jul 2021 23:48:05 +0000 (UTC) Received: by mail-pg1-f169.google.com with SMTP id w15so4130280pgk.13 for ; Wed, 14 Jul 2021 16:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RYJwbh9KOD42Nf9grsOeUnqWk613NdX1cSceZQgmFzY=; b=la5Lzin/p9l6kMKFGi0nSnGoTD6/D3mcyh4lmt+Zx3MPG/CRQRg1LvlrPpYxvATPsH NltxhoZzZIIklEW1LExZH+14Um8mvy632/UM6d9us1de7T5yN7zFfDjsZX88Y3m5ncow Z8pjNyH1nXg7FY3zgD/vxEZRDlsUtERtYWTfkjVHxDsYFEa4cEFMp+Ks1BVr6Wi6zRkY PlCr8h5ooOIk5PADZpi2Nvo8AzjQHLSIbpnjaQSeL79IDJ9azobM6NlplSs0/zjxUN9Y VGLNeFK+YLgk/Gplp4Dlt6yPwlUvvUnmNOhl1PYuoJdbSZ2cIjamdnVMPAIfNxVtblGf 97jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RYJwbh9KOD42Nf9grsOeUnqWk613NdX1cSceZQgmFzY=; b=CQZLT5iC+beJB6MIwRrLMRN12McyjNVElpK3y3ASW75m4YZuwbph/WOT4HyvvJzLMv okovu8bq6pCqWRk6gbR46HNSd+7YxazpZPmI0yhXHwASEBHllM09dMcV/9UjDGuvqr// oY9qcq64inV9jVN/C69k60E1E7snhrXOozVE1nCmLUjUvOtrUMiadK8hmXI+MNJgH7Hk GCx0ULpUvPVGA+1m00sSGLTfJD/e7MBoZURBk8dsOeItdrfz+v3PfyCZq6uK5Mi5/7gs Rp/ikGkBPfDW3dzuAwXLuwuRxbv25+CavX12J8VNwopU4pnStER3n2L74rAVSWSWD+YG N/Rw== X-Gm-Message-State: AOAM531QB/+XmVQdyZnuJVaxNvTUzFypaYf/a/lecojkbF2t44lxZOX/ dlZAjol3GtueDu+WGW3MPTwR6mcVXHPafqCczFdwQw== X-Google-Smtp-Source: ABdhPJwneGCuIIVoUCtM9q9uOOW140VZfTV5NbZkp/6lBrGpkRU0Bdxnv37+tn9M3sWDwBLiq5jWR9FnjE1VcTRpaKk= X-Received: by 2002:a63:4c3:: with SMTP id 186mr587774pge.240.1626306484737; Wed, 14 Jul 2021 16:48:04 -0700 (PDT) MIME-Version: 1.0 References: <20210714193542.21857-1-joao.m.martins@oracle.com> <20210714144830.29f9584878b04903079ef7eb@linux-foundation.org> In-Reply-To: <20210714144830.29f9584878b04903079ef7eb@linux-foundation.org> From: Dan Williams Date: Wed, 14 Jul 2021 16:47:53 -0700 Message-ID: Subject: Re: [PATCH v3 00/14] mm, sparse-vmemmap: Introduce compound pagemaps To: Andrew Morton Cc: Joao Martins , Linux MM , Vishal Verma , Dave Jiang , Naoya Horiguchi , Matthew Wilcox , Jason Gunthorpe , John Hubbard , Jane Chu , Muchun Song , Mike Kravetz , Jonathan Corbet , Linux NVDIMM , Linux Doc Mailing List Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=intel-com.20150623.gappssmtp.com header.s=20150623 header.b="la5Lzin/"; spf=none (imf15.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.215.169) smtp.mailfrom=dan.j.williams@intel.com; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none) X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: F0128D0000B4 X-Stat-Signature: xbrq7fxuxddwfhsjw8134bntef5jq147 X-HE-Tag: 1626306485-792731 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jul 14, 2021 at 2:48 PM Andrew Morton wrote: > > On Wed, 14 Jul 2021 20:35:28 +0100 Joao Martins 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.