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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9D3A2C433EF for ; Fri, 19 Nov 2021 19:53:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2C927610A1 for ; Fri, 19 Nov 2021 19:53:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2C927610A1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 9FA816B006C; Fri, 19 Nov 2021 14:53:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9AAC06B0071; Fri, 19 Nov 2021 14:53:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 84AEA6B0073; Fri, 19 Nov 2021 14:53:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0195.hostedemail.com [216.40.44.195]) by kanga.kvack.org (Postfix) with ESMTP id 7274E6B006C for ; Fri, 19 Nov 2021 14:53:35 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 36C948B76C for ; Fri, 19 Nov 2021 19:53:25 +0000 (UTC) X-FDA: 78826729170.28.606CD92 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by imf27.hostedemail.com (Postfix) with ESMTP id AD8EC7000081 for ; Fri, 19 Nov 2021 19:53:23 +0000 (UTC) Received: by mail-qk1-f177.google.com with SMTP id a11so11293565qkh.13 for ; Fri, 19 Nov 2021 11:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Bem5tnbrXl3B/iwkwWwNg7vN0haz/7ZDUvhQndVucnE=; b=CaIAO4aWkOeuLcdO7CEc7KdIBXFuSmlVdz4MeL3UU2h3B4lH2bWv+w3LIa/Gcli7oE 70wCHvw5RlRNegLrzO5AVOp/TDNCKMPIXRAWK2JHqda3qN231Axi36wsZRM3CZRX0p/o YElcBdY9bgdMh6ZdrqEtjfNCECrOcEOryjC/zv6xDFeWUwDQ1RQFnkaepnMKGqOmoXCN PODikGoYruO90Nlf9mnPWnbWERA0toT9VjiV1ybmzpAbtvj0mauNq+l5I32sIwLqq8zs WWj/ejMySUGWi2F2nVfXRccWiRaTsEz+JwvOSCkRp3n7e2LBZ/8I2I+tHqAsiQacNEzs myiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Bem5tnbrXl3B/iwkwWwNg7vN0haz/7ZDUvhQndVucnE=; b=w7giDaSReuVWqMjFIpbt+5gDoqxM7NpdXT/JKdfSs0PlIlYACeOLdTo08TfDjCX3rf Sc+Qop3z3SA3c4NF7Fgk8xou+oMTyIQ9IwRsB5JO7RGbUEoacu01ewBKI7FVxvLiNUw8 iOlAHGv+WJkwZV07vMABUmeONPyqjnoANDka6SY/VoPZOPW/JN//ij1k3HmnvGFUVKRo Kgsvdjg+wubT+4hOa8I0o2r8rfbUO/Zoaj2FEML+cLwDx/oA6A6FVEE94LQ2kC1DevwV F+/+OXl+VuKEY7E94iG+lm4iLDYmNYqdkTBYkVBOZSzqu8skcT3xg6CJIBI9Lx7gFqnP kVQA== X-Gm-Message-State: AOAM5305lwlfBP46/Zk40/Bny2L2r7t1tQX9idPjravMu5WxDtqYuhnQ PyqsOf2RWhRrz66YyevyVPxOsw== X-Google-Smtp-Source: ABdhPJw+XdqNjKdmy9zwEMzjYXbAuSof16x0lBbL2V/PrSLCnH4fzk8wxQUZsMLui4Ux0+dRGBd1MQ== X-Received: by 2002:a05:620a:998:: with SMTP id x24mr31096157qkx.117.1637351604134; Fri, 19 Nov 2021 11:53:24 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id y11sm459169qta.6.2021.11.19.11.53.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Nov 2021 11:53:23 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1mo9wo-00CdnM-U9; Fri, 19 Nov 2021 15:53:22 -0400 Date: Fri, 19 Nov 2021 15:53:22 -0400 From: Jason Gunthorpe To: Joao Martins Cc: Dan Williams , linux-mm@kvack.org, Vishal Verma , Dave Jiang , Naoya Horiguchi , Matthew Wilcox , John Hubbard , Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton , Jonathan Corbet , Christoph Hellwig , nvdimm@lists.linux.dev, linux-doc@vger.kernel.org Subject: Re: [PATCH v5 8/8] device-dax: compound devmap support Message-ID: <20211119195322.GN876299@ziepe.ca> References: <20211112150824.11028-1-joao.m.martins@oracle.com> <20211112150824.11028-9-joao.m.martins@oracle.com> <20211112153404.GD876299@ziepe.ca> <01f36268-4010-ecea-fee5-c128dd8bb179@oracle.com> <20211115164909.GF876299@ziepe.ca> <4d74bfb8-2cff-237b-321b-05aff34c1e5d@oracle.com> <3b7f9516-a35a-e46e-83d4-3059a959d221@oracle.com> <20211119165530.GJ876299@ziepe.ca> <6925ff6e-2cd5-574c-7802-e436a9a2a938@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6925ff6e-2cd5-574c-7802-e436a9a2a938@oracle.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: AD8EC7000081 X-Stat-Signature: t7xz3w8rqnycw4gesbjhjkzupxthsgpa Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=CaIAO4aW; dmarc=none; spf=pass (imf27.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.222.177 as permitted sender) smtp.mailfrom=jgg@ziepe.ca X-HE-Tag: 1637351603-702019 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 Fri, Nov 19, 2021 at 07:26:44PM +0000, Joao Martins wrote: > On 11/19/21 16:55, Jason Gunthorpe wrote: > > On Fri, Nov 19, 2021 at 04:12:18PM +0000, Joao Martins wrote: > > > >>> Dan, any thoughts (see also below) ? You probably hold all that > >>> history since its inception on commit 2232c6382a4 ("device-dax: Enable page_mapping()") > >>> and commit 35de299547d1 ("device-dax: Set page->index"). > >>> > >> Below is what I have staged so far as a percursor patch (see below scissors mark). > >> > >> It also lets me simplify compound page case for __dax_set_mapping() in this patch, > >> like below diff. > >> > >> But I still wonder whether this ordering adjustment of @mapping setting is best placed > >> as a percursor patch whenever pgmap/page refcount changes happen. Anyways it's just a > >> thought. > > > > naively I would have thought you'd set the mapping on all pages when > > you create the address_space and allocate pages into it. > > Today in fsdax/device-dax (hugetlb too) this is set on fault and set once > only (as you say) on the mapped pages. fsdax WARN_ON() you when you clearing > a page mapping that was not set to the expected address_space (similar to > what I did here) I would imagine that a normal FS case is to allocate some new memory and then join it to the address_space and set mapping, so that makes sense. For fsdax, logically the DAX pages on the medium with struct pages could be in the address_space as soon as the inode is created. That would improve fault performance at the cost of making address_space creation a lot slower, so I can see why not to do that. > > AFAIK devmap > > assigns all pages to a single address_space, so shouldn't the mapping > > just be done once? > Isn't it a bit more efficient that you set only when you try to map a page? For devdax if you can set the address space as part of initializing each struct page and setting the compounds it would probably be a net win? Anyhow, I think what you did here is OK? Maybe I don't understand the question 'whenever pgmap/page refcount changes happen' Jason