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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 BF863C433E6 for ; Fri, 12 Mar 2021 05:54:56 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6E08764F7B for ; Fri, 12 Mar 2021 05:54:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E08764F7B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 3EF48100EAB45; Thu, 11 Mar 2021 21:54:56 -0800 (PST) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::631; helo=mail-ej1-x631.google.com; envelope-from=dan.j.williams@intel.com; receiver= Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 27DE2100EAB43 for ; Thu, 11 Mar 2021 21:54:52 -0800 (PST) Received: by mail-ej1-x631.google.com with SMTP id r17so51066767ejy.13 for ; Thu, 11 Mar 2021 21:54:52 -0800 (PST) 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=wfgrhjBFwEzFBFXqj/JElN7KHjfc0N5GV2L7MtyLc5s=; b=kcM7AexuPVJk9B4qmDAk0W9+zQXLkef8Akxk8pygIsqz2+9m4CHZBnCQr0vqBUg5BK JvMV2o7qoJJiWKFAyHG2Zf7KCJnL6D9OR4DT92rOqTDnvKh4wDqvPzWcU+0GFXJimW6I wRjIZWOb/N+TKRv0+RL6FKvyTWNYr1DbgDrrFYkAIdojbUb2vqcu6JVQHzbZzSr5HAPp qgfx+kGvkG758PzUYqQQFvb61w8eoz2AI/ryXzkEc1V1HKa9R0qoW96BMaTz1Q+znSPM oUZn96cjk7Hr7NTYOitC1LWLRPdWjLWJnFIGRKwQ1whI/ea4lh4s6AYmUnQyI5UZOpGi mSxA== 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=wfgrhjBFwEzFBFXqj/JElN7KHjfc0N5GV2L7MtyLc5s=; b=XnGcgZ18g5tvrARsmQTnAQyTIT+EA2f9uQ/h0zACbilsN2jfeY2iKhZjpXLIIjRRqQ QHICgGQB08gGEL5JIP0rMwLIpG5BM8ISQXZ2t274CTg29OvkhT+4znwGOizFEbRRDLTq n3hov4Tg95azHOtLpHYNwpFpg+c4nB4+dzEs+Oa6AzbriqRRyvpK3PHR4mUWC6Kbx8wG ZLDFl7Pxju/5iS5a3JKRVjEAeYDhdII+5jLx/Hc3gY1BjQXe/C4/uwLX2LENgSZwSVz6 G7wk34ridY7D+Tn7L/blawjg98Dd0Hu+mj0I0wIIJzkJGiZcZlh0v9SoT/ae40xaWbuS ME6A== X-Gm-Message-State: AOAM532mpLu8lU+ylEbbRhYkebNdJRhgc1ZgU91aGFiQkegr5Yk9J+8b MC85lavoZZicnSrTERJPq3KO3jGMBeaJo1y0SZfLRQ== X-Google-Smtp-Source: ABdhPJxKfBvYG+kNLXc0u3fjseSeVl6oGe2f7JFYk7AhyGUudU+A7Fg1UaCUTv/tyj459F+m5ctZ3O5GiuonO61gxio= X-Received: by 2002:a17:906:c405:: with SMTP id u5mr6750672ejz.341.1615528490911; Thu, 11 Mar 2021 21:54:50 -0800 (PST) MIME-Version: 1.0 References: <20201208172901.17384-1-joao.m.martins@oracle.com> <20201208172901.17384-2-joao.m.martins@oracle.com> <7249cfd2-c178-2e6a-6b03-307a05f11785@nvidia.com> <7e8908ca-4d0f-6549-0442-d4b15fbc90ab@oracle.com>

In-Reply-To: From: Dan Williams Date: Thu, 11 Mar 2021 21:54:40 -0800 Message-ID: Subject: Re: [PATCH RFC 1/9] memremap: add ZONE_DEVICE support for compound pages To: Joao Martins Message-ID-Hash: 3JKQQ23RN3URG77SJKAPGZTLNHATZDF7 X-Message-ID-Hash: 3JKQQ23RN3URG77SJKAPGZTLNHATZDF7 X-MailFrom: dan.j.williams@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: Linux MM , linux-nvdimm , Matthew Wilcox , Jason Gunthorpe , Muchun Song , Mike Kravetz , Andrew Morton , John Hubbard X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Mar 10, 2021 at 10:13 AM Joao Martins wrote: > > On 2/22/21 8:37 PM, Dan Williams wrote: > > On Mon, Feb 22, 2021 at 3:24 AM Joao Martins wrote: > >> On 2/20/21 1:43 AM, Dan Williams wrote: > >>> On Tue, Dec 8, 2020 at 9:59 PM John Hubbard wrote: > >>>> On 12/8/20 9:28 AM, Joao Martins wrote: > >> One thing to point out about altmap is that the degradation (in pinning and > >> unpining) we observed with struct page's in device memory, is no longer observed > >> once 1) we batch ref count updates as we move to compound pages 2) reusing > >> tail pages seems to lead to these struct pages staying more likely in cache > >> which perhaps contributes to dirtying a lot less cachelines. > > > > True, it makes it more palatable to survive 'struct page' in PMEM, > > I want to retract for now what I said above wrt to the no degradation with > struct page in device comment. I was fooled by a bug on a patch later down > this series. Particular because I accidentally cleared PGMAP_ALTMAP_VALID when > unilaterally setting PGMAP_COMPOUND, which consequently lead to always > allocating struct pages from memory. No wonder the numbers were just as fast. > I am still confident that it's going to be faster and observe less degradation > in pinning/init. Init for now is worst-case 2x faster. But to be *as fast* struct > pages in memory might still be early to say. > > The broken masking of the PGMAP_ALTMAP_VALID bit did hide one flaw, where > we don't support altmap for basepages on x86/mm and it apparently depends > on architectures to implement it (and a couple other issues). The vmemmap > allocation isn't the problem, so the previous comment in this thread that > altmap doesn't change much in the vmemmap_populate_compound_pages() is > still accurate. > > The problem though resides on the freeing of vmemmap pagetables with > basepages *with altmap* (e.g. at dax-device teardown) which require arch > support. Doing it properly would mean making the altmap reserve smaller > (given fewer pages are allocated), and the ability for the altmap pfn > allocator to track references per pfn. But I think it deserves its own > separate patch series (probably almost just as big). > > Perhaps for this set I can stick without altmap as you suggested, and > use hugepage vmemmap population (which wouldn't > lead to device memory savings) instead of reusing base pages . I would > still leave the compound page support logic as metadata representation > for > 4K @align, as I think that's the right thing to do. And then > a separate series onto improving altmap to leverage the metadata reduction > support as done with non-device struct pages. > > Thoughts? The space savings is the whole point. So I agree with moving altmap support to a follow-on enhancement, but land the non-altmap basepage support in the first round. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org 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 AB498C433DB for ; Fri, 12 Mar 2021 05:54:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5D07264F82 for ; Fri, 12 Mar 2021 05:54:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D07264F82 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 78DAB8D0329; Fri, 12 Mar 2021 00:54:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7648F8D0317; Fri, 12 Mar 2021 00:54:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DFB48D0329; Fri, 12 Mar 2021 00:54:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0254.hostedemail.com [216.40.44.254]) by kanga.kvack.org (Postfix) with ESMTP id 3AA2E8D0317 for ; Fri, 12 Mar 2021 00:54:53 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id DF3634DCA for ; Fri, 12 Mar 2021 05:54:52 +0000 (UTC) X-FDA: 77910158424.10.B6F93A4 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf03.hostedemail.com (Postfix) with ESMTP id C11AFC0001FE for ; Fri, 12 Mar 2021 05:54:49 +0000 (UTC) Received: by mail-ej1-f47.google.com with SMTP id dx17so51131140ejb.2 for ; Thu, 11 Mar 2021 21:54:51 -0800 (PST) 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=wfgrhjBFwEzFBFXqj/JElN7KHjfc0N5GV2L7MtyLc5s=; b=kcM7AexuPVJk9B4qmDAk0W9+zQXLkef8Akxk8pygIsqz2+9m4CHZBnCQr0vqBUg5BK JvMV2o7qoJJiWKFAyHG2Zf7KCJnL6D9OR4DT92rOqTDnvKh4wDqvPzWcU+0GFXJimW6I wRjIZWOb/N+TKRv0+RL6FKvyTWNYr1DbgDrrFYkAIdojbUb2vqcu6JVQHzbZzSr5HAPp qgfx+kGvkG758PzUYqQQFvb61w8eoz2AI/ryXzkEc1V1HKa9R0qoW96BMaTz1Q+znSPM oUZn96cjk7Hr7NTYOitC1LWLRPdWjLWJnFIGRKwQ1whI/ea4lh4s6AYmUnQyI5UZOpGi mSxA== 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=wfgrhjBFwEzFBFXqj/JElN7KHjfc0N5GV2L7MtyLc5s=; b=pSDWYcqr3BoNS/HZswgS4X1vSM2x5+sVoZC/xCEc7jDe+22Q3BcvSVAdComBsQRPXJ IYo1PN2st/DrVxh4y1gfdHpUTK1Q3wSJwOTjCGEe4vKSjT2UeOjcqkfjqAxnPYvS2Xxu RhOhK4kJnZKOjh7oWNpq0G+qqWOLtrYxkCiRm1wMn5QZ3Y4/sz8KC9mIjTpG06CrF5lj Evj9O6Xf2d+cnZu3chxQA09nouRMBdfITY/Yz/GUaEG+3egM5+iHskskt36UPv4bnh1f qAPXh2xwbC5KR225ABalEwqFn7PT4kAgB1583GyWZl18xQ3UPr0bCpvkrym4sXXNFV/U 2cMw== X-Gm-Message-State: AOAM532YOW6e+jghXSbcyWnRLeWouL8/mUiAxudULHXKvdv+A7CywoaC 0snbUjyZe5iT9+SSGbsspRaU4ZCzka5cYfeUlp3raQ== X-Google-Smtp-Source: ABdhPJxKfBvYG+kNLXc0u3fjseSeVl6oGe2f7JFYk7AhyGUudU+A7Fg1UaCUTv/tyj459F+m5ctZ3O5GiuonO61gxio= X-Received: by 2002:a17:906:c405:: with SMTP id u5mr6750672ejz.341.1615528490911; Thu, 11 Mar 2021 21:54:50 -0800 (PST) MIME-Version: 1.0 References: <20201208172901.17384-1-joao.m.martins@oracle.com> <20201208172901.17384-2-joao.m.martins@oracle.com> <7249cfd2-c178-2e6a-6b03-307a05f11785@nvidia.com> <7e8908ca-4d0f-6549-0442-d4b15fbc90ab@oracle.com>

In-Reply-To: From: Dan Williams Date: Thu, 11 Mar 2021 21:54:40 -0800 Message-ID: Subject: Re: [PATCH RFC 1/9] memremap: add ZONE_DEVICE support for compound pages To: Joao Martins Cc: Linux MM , Ira Weiny , linux-nvdimm , Matthew Wilcox , Jason Gunthorpe , Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton , John Hubbard Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C11AFC0001FE X-Stat-Signature: y9jy9bix7r85gcgg9d1uim4k3dzz3p65 Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf03; identity=mailfrom; envelope-from=""; helo=mail-ej1-f47.google.com; client-ip=209.85.218.47 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615528489-335589 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, Mar 10, 2021 at 10:13 AM Joao Martins wrote: > > On 2/22/21 8:37 PM, Dan Williams wrote: > > On Mon, Feb 22, 2021 at 3:24 AM Joao Martins wrote: > >> On 2/20/21 1:43 AM, Dan Williams wrote: > >>> On Tue, Dec 8, 2020 at 9:59 PM John Hubbard wrote: > >>>> On 12/8/20 9:28 AM, Joao Martins wrote: > >> One thing to point out about altmap is that the degradation (in pinning and > >> unpining) we observed with struct page's in device memory, is no longer observed > >> once 1) we batch ref count updates as we move to compound pages 2) reusing > >> tail pages seems to lead to these struct pages staying more likely in cache > >> which perhaps contributes to dirtying a lot less cachelines. > > > > True, it makes it more palatable to survive 'struct page' in PMEM, > > I want to retract for now what I said above wrt to the no degradation with > struct page in device comment. I was fooled by a bug on a patch later down > this series. Particular because I accidentally cleared PGMAP_ALTMAP_VALID when > unilaterally setting PGMAP_COMPOUND, which consequently lead to always > allocating struct pages from memory. No wonder the numbers were just as fast. > I am still confident that it's going to be faster and observe less degradation > in pinning/init. Init for now is worst-case 2x faster. But to be *as fast* struct > pages in memory might still be early to say. > > The broken masking of the PGMAP_ALTMAP_VALID bit did hide one flaw, where > we don't support altmap for basepages on x86/mm and it apparently depends > on architectures to implement it (and a couple other issues). The vmemmap > allocation isn't the problem, so the previous comment in this thread that > altmap doesn't change much in the vmemmap_populate_compound_pages() is > still accurate. > > The problem though resides on the freeing of vmemmap pagetables with > basepages *with altmap* (e.g. at dax-device teardown) which require arch > support. Doing it properly would mean making the altmap reserve smaller > (given fewer pages are allocated), and the ability for the altmap pfn > allocator to track references per pfn. But I think it deserves its own > separate patch series (probably almost just as big). > > Perhaps for this set I can stick without altmap as you suggested, and > use hugepage vmemmap population (which wouldn't > lead to device memory savings) instead of reusing base pages . I would > still leave the compound page support logic as metadata representation > for > 4K @align, as I think that's the right thing to do. And then > a separate series onto improving altmap to leverage the metadata reduction > support as done with non-device struct pages. > > Thoughts? The space savings is the whole point. So I agree with moving altmap support to a follow-on enhancement, but land the non-altmap basepage support in the first round.