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 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 BAE8CC2B9F4 for ; Mon, 14 Jun 2021 23:07:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 31B2661350 for ; Mon, 14 Jun 2021 23:07:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 31B2661350 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 A2CF36B006C; Mon, 14 Jun 2021 19:07:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DD126B006E; Mon, 14 Jun 2021 19:07:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87DDB6B0070; Mon, 14 Jun 2021 19:07:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0083.hostedemail.com [216.40.44.83]) by kanga.kvack.org (Postfix) with ESMTP id 534DA6B006C for ; Mon, 14 Jun 2021 19:07:50 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E63DD2470 for ; Mon, 14 Jun 2021 23:07:49 +0000 (UTC) X-FDA: 78253868658.14.A8CBE68 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf04.hostedemail.com (Postfix) with ESMTP id 9CC60540 for ; Mon, 14 Jun 2021 23:07:43 +0000 (UTC) Received: by mail-pl1-f169.google.com with SMTP id 11so7433383plk.12 for ; Mon, 14 Jun 2021 16:07:48 -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=d34POHKKhyaLMu0FO3W3g/xVgLokZvIMWmd2dthb3bw=; b=lLlmi4tC13F1TK45l2XTdQeNZ8/hL8EOzQ7ZBIzYU+7Vqf7wRYUhN+8vihBfpZhddp Ko2y8bGBk8EnS8suRS3z19vLz6IsjFTUStnKTmT3tD3H+EnnKMRilwnvpdHdWcyrlkrB mS+9OjzphYSEotypDl01bsuMjmoFIv3uzEJFbQKdjd4cr21EY6fXjLOoLIpemO2N96ZA A/i4IzMeRUaARe+dRpXrGQKynRnO5oquomKOvayiTCU4yhARB5TDzl7DBbczNW9uygR2 ijuXdjBIFnSUtTJVBp2D0F8MCiO3T+0oz9YG6JtZLZjiGFlMNSJi5rGl48sYlRTE6Ot6 JBFA== 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=d34POHKKhyaLMu0FO3W3g/xVgLokZvIMWmd2dthb3bw=; b=e98zTTDI4JLcLhbZqKHseCg7FUTq6fZLzXFwecvDsBufV0w9aqI836xxVsiXuj2nS8 4aHohgSRuVtikDMPP0qM1e8MkckXNh14/9yPMY0HkC5AMXB8y0cfPZkUAKz/ODZOPm6u afr+sl5fainpF/OP4ULGzr71E3Nqo6kcW8lMDlr98tiznIkI9jhJzZB/QlGZVoNe8HRH KotgYKaBC+Xv/X51VSgHesuCUMlQhFMkwHGkhpOdeoBq6TbFNHyZY7MYMd5LkaMxZHLZ 44prWrc4Wy7VYK6RNetVkFWGy2LXyyw2l665tjVPi0qQ1SX5nSvW14foFw9sfRBBrcR3 Lu8Q== X-Gm-Message-State: AOAM531wziSV6E5RZanLx0425KLiXWzP+ys+3cKqrEvhDnH1rs9Aki0C 8pC3iTIuhDyI6cUrilbXtmrR2h8RzatwSDYKZgWVTg== X-Google-Smtp-Source: ABdhPJye2JFs2r7cRXUYh1/xlrBndOcwMtVHEgzynnDM5vubY5fSvn4OJLEvPnFlctR1jXG5IvrBQrcEdckMP6zUzVo= X-Received: by 2002:a17:90a:ea8c:: with SMTP id h12mr1496149pjz.149.1623712068139; Mon, 14 Jun 2021 16:07:48 -0700 (PDT) MIME-Version: 1.0 References: <20210325230938.30752-1-joao.m.martins@oracle.com> <20210325230938.30752-10-joao.m.martins@oracle.com> <840290bd-55cc-e77a-b13d-05c6fd361865@oracle.com> <0c6a4dab-296d-94b2-f885-2371292f9e0d@oracle.com> In-Reply-To: <0c6a4dab-296d-94b2-f885-2371292f9e0d@oracle.com> From: Dan Williams Date: Mon, 14 Jun 2021 16:07:36 -0700 Message-ID: Subject: Re: [PATCH v1 09/11] mm/page_alloc: reuse tail struct pages for compound pagemaps To: Joao Martins Cc: Linux MM , Linux NVDIMM , Ira Weiny , Matthew Wilcox , Jason Gunthorpe , Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=intel-com.20150623.gappssmtp.com header.s=20150623 header.b=lLlmi4tC; spf=none (imf04.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.214.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: 9CC60540 X-Stat-Signature: prbrgqoohp5ix3t4f99p5yjroq6gqcnf X-HE-Tag: 1623712063-184278 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jun 14, 2021 at 11:42 AM Joao Martins wrote: > > > > On 6/7/21 8:32 PM, Dan Williams wrote: > > On Mon, Jun 7, 2021 at 6:49 AM Joao Martins wrote: > > [..] > >>> Given all of the above I'm wondering if there should be a new > >>> "compound specific" flavor of this routine rather than trying to > >>> cleverly inter mingle the old path with the new. This is easier > >>> because you have already done the work in previous patches to break > >>> this into helpers. So just have memmap_init_zone_device() do it the > >>> "old" way and memmap_init_compound() handle all the tail page init + > >>> optimizations. > >>> > >> I can separate it out, should be easier to follow. > >> > >> Albeit just a note, I think memmap_init_compound() should be the new normal as metadata > >> more accurately represents what goes on the page tables. That's regardless of > >> vmemmap-based gains, and hence why my train of thought was to not separate it. > >> > >> After this series, all devmap pages where @geometry matches @align will have compound > >> pages be used instead. And we enable that in device-dax as first user (in the next patch). > >> altmap or not so far just differentiates on the uniqueness of struct pages as the former > >> doesn't reuse base pages that only contain tail pages and consequently makes us initialize > >> all tail struct pages. > > > > I think combining the cases into a common central routine makes the > > code that much harder to maintain. A small duplication cost is worth > > it in my opinion to help readability / maintainability. > > > I am addressing this comment and taking a step back. By just moving the tail page init to > memmap_init_compound() this gets a lot more readable. Albeit now I think having separate > top-level loops over pfns, doesn't bring much improvement there. > > Here's what I have by moving just tails init to a separate routine. See your original > suggestion after the scissors mark. I have a slight inclination towards the first one, but > no really strong preference. Thoughts? I like your "first one" too.