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 98BA2C433F5 for ; Tue, 19 Oct 2021 19:21:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4DC666137F for ; Tue, 19 Oct 2021 19:21:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4DC666137F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id B1B4F6B0072; Tue, 19 Oct 2021 15:21:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ACB236B0078; Tue, 19 Oct 2021 15:21:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E0FC6B007B; Tue, 19 Oct 2021 15:21:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0187.hostedemail.com [216.40.44.187]) by kanga.kvack.org (Postfix) with ESMTP id 84D006B0072 for ; Tue, 19 Oct 2021 15:21:22 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 64EC63A8E8 for ; Tue, 19 Oct 2021 19:21:21 +0000 (UTC) X-FDA: 78714155562.19.061506E Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by imf09.hostedemail.com (Postfix) with ESMTP id 4FBAF3000105 for ; Tue, 19 Oct 2021 19:21:18 +0000 (UTC) Received: by mail-pj1-f43.google.com with SMTP id g13-20020a17090a3c8d00b00196286963b9so652568pjc.3 for ; Tue, 19 Oct 2021 12:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A0ozvNXsQJNcX/pewDd9ckpqp0ETylCl5PX4CkgxTjA=; b=dIpN/4YGGNH4r1EZENPOoUM36qbNMxX0AlEbDXR+QAUuWgDJulDqEi3wGiq/1+ers/ MtNK0sg7f9C/QkJyKAJlFRYKqMBrTfln8PJngSh8ITqopx0o8J1obkFmoFdux9294FXa 0ool0au7ytqQW+k+FPfqnMPWwg5vnKGiVhNgNjwxlfxeranZOVIdAnN2DTdpI6wVKD3S 78DmFolU0SXPPnnv6NF8puovRVgO1rRm/SJEGKuOaaGFJvzVcaTz85rlz8++NBOOAXd7 t/YIuxqKfUmA5B4vTl9lTDomRDwyKSQWYZDfBGBNdaXHm7+cgFxwO+idryj4IONEZqwU vC2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A0ozvNXsQJNcX/pewDd9ckpqp0ETylCl5PX4CkgxTjA=; b=iRppdtt/dGGetaF7NGhaFqifKJHwsSQZ9WjBRiKc/15PWxCavmnSSkuS2bga69lKQb jyCsm2A/Hk5+vOmEnKW2M/nF7MfVaeQYRNVxjHn1XxLttN5gMeNJG39UgtYH7aWd3Q7O QmmRzbprAxsdamnUQtB8+/NuRQE8uB8Q20gQ3h84+67b0DUuguSwQbT/POj4NA+8/ckS D4+ZKB/04PkTvpnd1IMaT0CMVLpMNdoivKSmxeGAJzTCDiBlaQq4sQPO1eZytFtNGK4B HkTJoV5rvZFfnRABb7dfK2syk2ETPKd4SYf4Ok/fnF4AxpquZnIEl32DPwPXT61yqZTu OcXg== X-Gm-Message-State: AOAM530RDyv/npK9pQqwRu0m92G5MO9RGrwLFzg+kmnegQFNZMqZ6/tn J7M31+LMaWLN4bgrbxsJ+KxOkMsGJ0zEQ3i+rJwV8w== X-Google-Smtp-Source: ABdhPJxnZNNxl4GB/nPoKZm/Jigqlqq+b5Yi5opJ2SeB60SRKWrnwAOzNK7EVcYCxhzXA3M9GeWcrmYdSBdgg3eEB9o= X-Received: by 2002:a17:90b:350f:: with SMTP id ls15mr1918933pjb.220.1634671278933; Tue, 19 Oct 2021 12:21:18 -0700 (PDT) MIME-Version: 1.0 References: <20211014230606.GZ2744544@nvidia.com> <20211016154450.GJ2744544@nvidia.com> <20211018182559.GC3686969@ziepe.ca> <20211018230614.GF3686969@ziepe.ca> <499043a0-b3d8-7a42-4aee-84b81f5b633f@oracle.com> <20211019160136.GH3686969@ziepe.ca> In-Reply-To: <20211019160136.GH3686969@ziepe.ca> From: Dan Williams Date: Tue, 19 Oct 2021 12:21:09 -0700 Message-ID: Subject: Re: [PATCH v1 2/2] mm: remove extra ZONE_DEVICE struct page refcount To: Jason Gunthorpe Cc: Joao Martins , Matthew Wilcox , Alex Sierra , Andrew Morton , "Kuehling, Felix" , Linux MM , Ralph Campbell , linux-ext4 , linux-xfs , amd-gfx list , Maling list - DRI developers , Christoph Hellwig , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Alistair Popple , Vishal Verma , Dave Jiang , Linux NVDIMM , David Hildenbrand Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4FBAF3000105 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel-com.20210112.gappssmtp.com header.s=20210112 header.b="dIpN/4YG"; spf=none (imf09.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.216.43) smtp.mailfrom=dan.j.williams@intel.com; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none) X-Stat-Signature: wiwj15j8iwb4gnbojhhqju5q9tfhht1s X-Rspamd-Server: rspam05 X-HE-Tag: 1634671278-823888 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, Oct 19, 2021 at 9:02 AM Jason Gunthorpe wrote: > > On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote: > > On 10/19/21 00:06, Jason Gunthorpe wrote: > > > On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote: > > > > > >>> device-dax uses PUD, along with TTM, they are the only places. I'm not > > >>> sure TTM is a real place though. > > >> > > >> I was setting device-dax aside because it can use Joao's changes to > > >> get compound-page support. > > > > > > Ideally, but that ideas in that patch series have been floating around > > > for a long time now.. > > > > > The current status of the series misses a Rb on patches 6,7,10,12-14. > > Well, patch 8 too should now drop its tag, considering the latest > > discussion. > > > > If it helps moving things forward I could split my series further into: > > > > 1) the compound page introduction (patches 1-7) of my aforementioned series > > 2) vmemmap deduplication for memory gains (patches 9-14) > > 3) gup improvements (patch 8 and gup-slow improvements) > > I would split it, yes.. > > I think we can see a general consensus that making compound_head/etc > work consistently with how THP uses it will provide value and > opportunity for optimization going forward. > > > Whats the benefit between preventing longterm at start > > versus only after mounting the filesystem? Or is the intended future purpose > > to pass more context into an holder potential future callback e.g. nack longterm > > pins on a page basis? > > I understood Dan's remark that the device-dax path allows > FOLL_LONGTERM and the FSDAX path does not ? > > Which, IIRC, today is signaled basd on vma properties and in all cases > fast-gup is denied. Yeah, I forgot that 7af75561e171 eliminated any possibility of longterm-gup-fast for device-dax, let's not disturb that status quo. > > Maybe we can start by at least not add any flags and just prevent > > FOLL_LONGTERM on fsdax -- which I guess was the original purpose of > > commit 7af75561e171 ("mm/gup: add FOLL_LONGTERM capability to GUP fast"). > > This patch (which I can formally send) has a sketch of that (below scissors mark): > > > > https://lore.kernel.org/linux-mm/6a18179e-65f7-367d-89a9-d5162f10fef0@oracle.com/ > > Yes, basically, whatever test we want for 'deny fast gup foll > longterm' is fine. > > Personally I'd like to see us move toward a set of flag specifying > each special behavior and not a collection of types that imply special > behaviors. > > Eg we have at least: > - Block gup fast on foll_longterm > - Capture the refcount ==1 and use the pgmap free hook > (confusingly called page_is_devmap_managed()) > - Always use a swap entry > - page->index/mapping are used in the usual file based way? > > Probably more things.. Yes, agree with the principle of reducing type-implied special casing.