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 E6C4CC433DB for ; Tue, 23 Feb 2021 18:18:39 +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 67ACB64E24 for ; Tue, 23 Feb 2021 18:18:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 67ACB64E24 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 3985F100EB350; Tue, 23 Feb 2021 10:18:39 -0800 (PST) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::634; helo=mail-ej1-x634.google.com; envelope-from=dan.j.williams@intel.com; receiver= Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 44630100EB34E for ; Tue, 23 Feb 2021 10:18:36 -0800 (PST) Received: by mail-ej1-x634.google.com with SMTP id w1so35847353ejf.11 for ; Tue, 23 Feb 2021 10:18:36 -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=k7TKOxtIPubSWBMdBmROKVMkCaaa3udkcxhiRusHIqg=; b=XT7ZogD44IGZSwnl04BuslsAjEFzJ54K3btpAhcBwuf6WnbZ9geKwvrOj/WSslmtn2 n90kKkhJoi4DgorKaqGYW8aUgNg+R9x6oYImDEA+wSAd0hZp6+qPFaP5uiUW3mKlBir5 fKwlKl59wHnn83RLfgbkhnOYCsVdFguKqFXZwry2v/gPBf4u2E9KCoaejJfi46T6u2O1 woC6FgOoK0xJ9tHBM4Pk5V6LHk31u+faK3twjPnbZhEYa+A1qxsKIUv04EpCjJThjqxh Z/MF5N4Rkg0HX9BHwljKFPK+ra6hCbfj2ngw0EyHOKgkNq7NySrGQa+SyN9KGJe+odJM GZ4Q== 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=k7TKOxtIPubSWBMdBmROKVMkCaaa3udkcxhiRusHIqg=; b=i/wZvmnFmAVtFaytCZACEEdE0OSeiki4jT+QEamrvZtSuxI9b9QfPgfGWAvR7DsYxa 7IYGvEJEk241q1dwgrBe/z1EA5na76qPr/SJY4D+eIKSQQUZB+ZHW7tSYJ34jmeVCCWx tzxatEjLx1Czf0Cy1oI792/UhqKB8zRqOhsgXZQc+Xr6x0nq+6/ssMjDdDyHKiGKJWoH sacAIE3yQVKyPcZFKkE/0KPnvlNJMPv4aBBXwH8U9TbQs+6vX/0YuXTKdxwPSDVS3rLZ CShka42RmG3e0alPK1o8I8rYU+I1wE0mfiZF1NFHZfwfGJd/1EA9yld7oGWMtvSaLAAk NwUw== X-Gm-Message-State: AOAM530/4eNgi1fg5CPixATXs021inm12UC38PT/BQOFjPIz2/UJuZPd 57REf9oOD19OUOVAi7gIOOqMYvSNt3RhWkEDcNoD0A== X-Google-Smtp-Source: ABdhPJw+XSq6g2M1vDuZGcjoJeTZChklC3kcuEWAG0F7PeXyjl6IA0fZFJsUFTY7Iwd8Vbi543a4Lc1mg1RgWaLthjY= X-Received: by 2002:a17:906:e0b:: with SMTP id l11mr20720810eji.523.1614104314865; Tue, 23 Feb 2021 10:18:34 -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> <94075df6-ab3b-c6e4-13f1-26dd266dbf82@oracle.com>

In-Reply-To: From: Dan Williams Date: Tue, 23 Feb 2021 10:18:30 -0800 Message-ID: Subject: Re: [PATCH RFC 1/9] memremap: add ZONE_DEVICE support for compound pages To: Joao Martins Message-ID-Hash: GYKVAXO7US76D5C3PJLPNZ2V5PRVS3AR X-Message-ID-Hash: GYKVAXO7US76D5C3PJLPNZ2V5PRVS3AR 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 Tue, Feb 23, 2021 at 9:19 AM Joao Martins wrote: > > On 2/23/21 4:50 PM, Dan Williams wrote: > > On Tue, Feb 23, 2021 at 7:46 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: > > [...] > > >>> Don't get me wrong the > >>> capability is still needed for filesystem-dax, but the distinction is > >>> that vmemmap_populate_compound_pages() need never worry about an > >>> altmap. > >>> > >> IMO there's not much added complexity strictly speaking about altmap. We still use the > >> same vmemmap_{pmd,pte,pgd}_populate helpers which just pass an altmap. So whatever it is > >> being maintained for fsdax or other altmap consumers (e.g. we seem to be working towards > >> hotplug making use of it) we are using it in the exact same way. > >> > >> The complexity of the future vmemmap_populate_compound_pages() has more to do with reusing > >> vmemmap blocks allocated in previous vmemmap pages, and preserving that across section > >> onlining (for 1G pages). > > > > True, I'm less worried about the complexity as much as > > opportunistically converting configurations to RAM backed pages. It's > > already the case that poison handling is page mapping size aligned for > > device-dax, and filesystem-dax needs to stick with non-compound-pages > > for the foreseeable future. > > > Hmm, I was sort off wondering that fsdax could move to compound pages too as > opposed to base pages, albeit not necessarily using the vmemmap page reuse > as it splits pages IIUC. I'm not sure compound pages for fsdax would work long term because there's no infrastructure to reassemble compound pages after a split. So if you fracture a block and then coalesce it back to a 2MB or 1GB aligned block there's nothing to go fixup the compound page... unless the filesystem wants to get into mm metadata fixups. _______________________________________________ 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.7 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 8E3C8C433DB for ; Tue, 23 Feb 2021 18:18:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 340D964DD3 for ; Tue, 23 Feb 2021 18:18:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 340D964DD3 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 B6C316B0005; Tue, 23 Feb 2021 13:18:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B1E176B0006; Tue, 23 Feb 2021 13:18:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A0B676B006E; Tue, 23 Feb 2021 13:18:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 86E256B0005 for ; Tue, 23 Feb 2021 13:18:43 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 400201E08 for ; Tue, 23 Feb 2021 18:18:43 +0000 (UTC) X-FDA: 77850343326.30.BBC7058 Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) by imf29.hostedemail.com (Postfix) with ESMTP id 3D05CDE for ; Tue, 23 Feb 2021 18:18:36 +0000 (UTC) Received: by mail-ej1-f51.google.com with SMTP id j6so8881528eja.12 for ; Tue, 23 Feb 2021 10:18:35 -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=k7TKOxtIPubSWBMdBmROKVMkCaaa3udkcxhiRusHIqg=; b=XT7ZogD44IGZSwnl04BuslsAjEFzJ54K3btpAhcBwuf6WnbZ9geKwvrOj/WSslmtn2 n90kKkhJoi4DgorKaqGYW8aUgNg+R9x6oYImDEA+wSAd0hZp6+qPFaP5uiUW3mKlBir5 fKwlKl59wHnn83RLfgbkhnOYCsVdFguKqFXZwry2v/gPBf4u2E9KCoaejJfi46T6u2O1 woC6FgOoK0xJ9tHBM4Pk5V6LHk31u+faK3twjPnbZhEYa+A1qxsKIUv04EpCjJThjqxh Z/MF5N4Rkg0HX9BHwljKFPK+ra6hCbfj2ngw0EyHOKgkNq7NySrGQa+SyN9KGJe+odJM GZ4Q== 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=k7TKOxtIPubSWBMdBmROKVMkCaaa3udkcxhiRusHIqg=; b=TV6d/uZp54APecTNcK1v2oTpJnoJG8IKCcf74rsQCenpp+YYvka0oo2rxC50seaaMY wvARCqqD8i8qCnQ3pn4Mew57bo8isdbPPX1A0zrdPbnl1TJYUkolgRnWfARPT1/aDFul kYadjQeMswtb34MuplKx+KpKVIFOylvjlpbFEr6aAJF/k/ozV6EQzfMO33217TVUZWw4 nFrIQxvyaETEWmDMVSEvxjKR67DvZz7U/ed9Qw21tuMfho0FqPIwdKjjlJTRxWNN2WD2 nnbF7vAgxBvzNlZrwPd5fr/xgujwy3HQGUseLcI8nSfA4tM1WcBM2m23Xx3oh3l82iex 7baA== X-Gm-Message-State: AOAM533gpeIOmLkUZhMBrF5Zs7cPjGhoT35WiDTs+vyzXph+0H3LDfYL kO5aR5u4OXdBnxWErU+KzYK9ImODp84CEKzNbGZeBQ== X-Google-Smtp-Source: ABdhPJw+XSq6g2M1vDuZGcjoJeTZChklC3kcuEWAG0F7PeXyjl6IA0fZFJsUFTY7Iwd8Vbi543a4Lc1mg1RgWaLthjY= X-Received: by 2002:a17:906:e0b:: with SMTP id l11mr20720810eji.523.1614104314865; Tue, 23 Feb 2021 10:18:34 -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> <94075df6-ab3b-c6e4-13f1-26dd266dbf82@oracle.com>

In-Reply-To: From: Dan Williams Date: Tue, 23 Feb 2021 10:18:30 -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: rspam03 X-Rspamd-Queue-Id: 3D05CDE X-Stat-Signature: wn87cswykzhtc73wxgdhmwtm6icmg1te Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf29; identity=mailfrom; envelope-from=""; helo=mail-ej1-f51.google.com; client-ip=209.85.218.51 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614104316-956127 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 Tue, Feb 23, 2021 at 9:19 AM Joao Martins wrote: > > On 2/23/21 4:50 PM, Dan Williams wrote: > > On Tue, Feb 23, 2021 at 7:46 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: > > [...] > > >>> Don't get me wrong the > >>> capability is still needed for filesystem-dax, but the distinction is > >>> that vmemmap_populate_compound_pages() need never worry about an > >>> altmap. > >>> > >> IMO there's not much added complexity strictly speaking about altmap. We still use the > >> same vmemmap_{pmd,pte,pgd}_populate helpers which just pass an altmap. So whatever it is > >> being maintained for fsdax or other altmap consumers (e.g. we seem to be working towards > >> hotplug making use of it) we are using it in the exact same way. > >> > >> The complexity of the future vmemmap_populate_compound_pages() has more to do with reusing > >> vmemmap blocks allocated in previous vmemmap pages, and preserving that across section > >> onlining (for 1G pages). > > > > True, I'm less worried about the complexity as much as > > opportunistically converting configurations to RAM backed pages. It's > > already the case that poison handling is page mapping size aligned for > > device-dax, and filesystem-dax needs to stick with non-compound-pages > > for the foreseeable future. > > > Hmm, I was sort off wondering that fsdax could move to compound pages too as > opposed to base pages, albeit not necessarily using the vmemmap page reuse > as it splits pages IIUC. I'm not sure compound pages for fsdax would work long term because there's no infrastructure to reassemble compound pages after a split. So if you fracture a block and then coalesce it back to a 2MB or 1GB aligned block there's nothing to go fixup the compound page... unless the filesystem wants to get into mm metadata fixups.