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 5C047C47082 for ; Mon, 7 Jun 2021 20:13:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 15FDE610A2 for ; Mon, 7 Jun 2021 20:13:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 15FDE610A2 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 752046B006C; Mon, 7 Jun 2021 16:13:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7296C6B006E; Mon, 7 Jun 2021 16:13:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C9C26B0070; Mon, 7 Jun 2021 16:13:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 2DED56B006C for ; Mon, 7 Jun 2021 16:13:36 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id BD68E1A4C1 for ; Mon, 7 Jun 2021 20:13:35 +0000 (UTC) X-FDA: 78228027990.04.16417BE Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by imf27.hostedemail.com (Postfix) with ESMTP id B48808019E8E for ; Mon, 7 Jun 2021 20:13:26 +0000 (UTC) Received: by mail-pg1-f171.google.com with SMTP id y12so2869397pgk.6 for ; Mon, 07 Jun 2021 13:13:29 -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=0pBKeuTCvXTxfJLIrxIn01HYBpCXFmU59cc3AdYC+ZM=; b=USFvRAI3DDRrfLVlmElYTF7b6nH7qjBVPss7pcR2hvY+0xymsaGFF5uXe1u0j4lXPl xajafnpjF1Q6WaFdpHFgOcZPAYvXI7lIv8ZXoyxyxkvZSRw7ka4m+8KLXNvI1jBHk+x1 c/a0Q9uJdngGV0uEsmVXA2z6IuoAQybFohS3v5qanLQtPImWAR1NyellbGanP6QKn2hB pRbi+5qC3vnBlvCEwYDVGM0goRLCdr/RCPOStiatLblDZ86c8fG3bCWtoHEc2sNkSCVl vFG6ThrWHBUYepA4EJMNOQDytfVuqMsJ5Oaa/XRizhgTpIjLhAMOMLXc+19Wzvldbul4 9RHg== 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=0pBKeuTCvXTxfJLIrxIn01HYBpCXFmU59cc3AdYC+ZM=; b=RlahBMYtcjAxKsYX7Y1DNNnl8k7ZuZ30cgCamDnyK9CsjSiPyIyG37PA250SDnfzfZ YuUS7vYRvjFCBsqeZqHjAh5IBbnU8Je/PziqLQrTnsXCZSqu25wr4ysj97GsGalU/Qk9 2+m/q4LaETeTxSi5mQD3+Kp7ATyMq/g4Wo6bFokOc9t5Wcq9b7NWokU+swKzzmHpSxyt g/XMSOU10roMgJes+Kz/5QdPKBW3gDFzI6v0Y4pYDHlmf1DoSEHYqpjFuOjgS0/q2fpB q2OIvXm2pYOoHJZGNn2tvCZ1tSTKCxeJf/w2QeZxg44fPOSb9z0Y1slSgewY24YUb/te 5caA== X-Gm-Message-State: AOAM531QQe5hcHTOF5rnbIzzKpADb8oVxtLZBsbvgelLVMZZOpgevogm cvVoOo2HjKveE8P1DN5jq69rfp1THlzbWgbXgn+3OwBb6Lk= X-Google-Smtp-Source: ABdhPJxbWfAFiUDGvMg/U0bNFfH4c0B/MtPj4bZq08RF4W2egD51Sa91i8qmw8fag4hVaVudjqIQ9GV6j/5IOwqX7y4= X-Received: by 2002:a62:8287:0:b029:2ec:9b1f:9c0a with SMTP id w129-20020a6282870000b02902ec9b1f9c0amr15786887pfd.31.1623095255205; Mon, 07 Jun 2021 12:47:35 -0700 (PDT) MIME-Version: 1.0 References: <20210325230938.30752-1-joao.m.martins@oracle.com> <20210325230938.30752-9-joao.m.martins@oracle.com> <51dfb7d8-269d-5692-7c88-7b4084e996cc@oracle.com> In-Reply-To: <51dfb7d8-269d-5692-7c88-7b4084e996cc@oracle.com> From: Dan Williams Date: Mon, 7 Jun 2021 12:47:24 -0700 Message-ID: Subject: Re: [PATCH v1 08/11] mm/sparse-vmemmap: use hugepages for PUD compound pagemaps To: Joao Martins Cc: Linux MM , Ira Weiny , linux-nvdimm , Matthew Wilcox , Jason Gunthorpe , Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=intel-com.20150623.gappssmtp.com header.s=20150623 header.b=USFvRAI3; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none); spf=none (imf27.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.215.171) smtp.mailfrom=dan.j.williams@intel.com X-Stat-Signature: js3dd8s9yp47yqpsa56jz9mincz6kjmk X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B48808019E8E X-HE-Tag: 1623096806-815721 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 Mon, Jun 7, 2021 at 5:03 AM Joao Martins wrote: > > > > On 6/1/21 8:30 PM, Dan Williams wrote: > > Sorry for the delay, and the sync up on IRC. I think this subject > > needs to change to "optimize memory savings for compound pud memmap > > geometry", and move this to the back of the series to make it clear > > which patches are base functionality and which extend the idea > > further. > > OK > > > As far as I can see this patch can move to the end of the > > series. > > Maybe its prefered that this patch could be deferred to out of the series as > a followup improvement, and leave this series with the base feature set only? My preference is to keep it in just clarify that it's an optimization and make sure it does not come before any fundamental patches that implement the base support. > > Some additional changelog feedback below: > > > > > > On Thu, Mar 25, 2021 at 4:10 PM Joao Martins wrote: > >> > >> Right now basepages are used to populate the PUD tail pages, and it > >> picks the address of the previous page of the subsection that preceeds > > > > s/preceeds/precedes/ > > > Yeap. > > >> the memmap we are initializing. This is done when a given memmap > >> address isn't aligned to the pgmap @align (which is safe to do because > >> @ranges are guaranteed to be aligned to @align). > > > > You know what would help is if you could draw an ascii art picture of > > the before and after of the head page vs tail page arrangement. I can > > see how the words line up to the code, but it takes a while to get the > > picture in my head and I think future work in this area will benefit > > from having a place in Documentation that draws a picture of the > > layout of the various geometries. > > > Makes sense, I will add docs. Mike K. and others had similar trouble following > the page structs arrangement which ultimately lead to this section of commentary > at the beginning of the new source file added here ... > > https://www.ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-free-the-vmemmap-pages-associated-with-each-hugetlb-page.patch Ah, looks good, but that really belongs in Documentation/ not a comment block. > > > I've used asciiflow.com for these types of diagrams in the past. > > > > ... so perhaps I can borrow some of that and place it to > a common place like in Documentation/vm/compound_pagemaps.rst > > This patch specifically would need a new diagram added on top covering > the PMD page case. Sounds good. [..] > > Other than that the implementation looks ok to me, modulo previous > > comments about @block type and the use of the "geometry" term. > > > OK. > > Btw, speaking of geometry, could you have a look at this thread: > > https://lore.kernel.org/linux-mm/8c922a58-c901-1ad9-5d19-1182bd6dea1e@oracle.com/ > > .. and let me know what you think? Ok, will take a look