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 E3C9AC4332F for ; Wed, 20 Oct 2021 17:12:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 78B8B610D0 for ; Wed, 20 Oct 2021 17:12:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 78B8B610D0 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 06169940012; Wed, 20 Oct 2021 13:12:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F1F79900004; Wed, 20 Oct 2021 13:12:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D9986940012; Wed, 20 Oct 2021 13:12:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0084.hostedemail.com [216.40.44.84]) by kanga.kvack.org (Postfix) with ESMTP id C4041900004 for ; Wed, 20 Oct 2021 13:12:47 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8FB572DEBA for ; Wed, 20 Oct 2021 17:12:47 +0000 (UTC) X-FDA: 78717460374.36.5BAE67B Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by imf18.hostedemail.com (Postfix) with ESMTP id B67A14002092 for ; Wed, 20 Oct 2021 17:12:43 +0000 (UTC) Received: by mail-pf1-f173.google.com with SMTP id q19so3512735pfl.4 for ; Wed, 20 Oct 2021 10:12:46 -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=yh4VNQVbmqEE1XoY0HfdKCiOCUMZEFg9p2e4mySh1ho=; b=gXp+nm6KP18UxdU9Hk3ApH1mhWLfoJo59VGT/uI2ErBwWWyik4nmEDpSY+ZrwJRKsD 1m2G6rHPn7W/JZ+E3tckd4iJSTd6DrCA1haY52Re29y61eWHiifpVeHfZXxxVG0OyAIG SNKtPfTbbylxqWGsIA6ibBarKTRo4H14iXLyBREaAXG+H2DN8uhwtgKoCeWK8woL61v/ h3zf1b5/RLytsJ/EioaqOo91sbl+0/PnLuBJrtfYdYpnEHnps1RtQHpp6zHlZvn6BAf5 ILV5/M+yMBS3ApNMZ1KgMy5ldAYTELk9W2MzVGpH+zHnvMYELSkCHHRjl7R71WGss/j1 /9/Q== 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=yh4VNQVbmqEE1XoY0HfdKCiOCUMZEFg9p2e4mySh1ho=; b=ftMP5y+6qIFohaVD7AtMQJ5mbcFc60n1bE/WY0RuBeaxf+mSTAOSCqYK0+DIAvtpCm B/GzGLPlxky9S42IhfiL/S1v/HonreGUqmh2UIMgBeU/3+maJssZ404C/hf0WS3LNxJf pvbfLdfNd2BorV4w4p986SD6lt90EAZrqQt5mymBWXdZq0YZ1GhQLsI1Pi+eUNoELu9h YgeyoGnTFgB1LQvu+D4LPjDgUerG01MVoNg0Ld2Zx7iil93qX6aQ7sHdJ0g1KjqDRqk3 I0zA0XUMc9KAoOsbPAmG0DCWw7agr4C3QqIz7BUhuUmUjIYbWc/wxOupTftz5wMh/K95 08Ew== X-Gm-Message-State: AOAM533hheygNewXe+Ei4jPEyQgZxRUzZvos5LUO0Sbp0U1VxMQ2wtnI TTgY4dDJuniNSGXLfoCR/GIll6Fglbq4VUIZhXUO1A== X-Google-Smtp-Source: ABdhPJwX0GE82e3GMz46Z+6E2d1Wq5pKde1k4jJ2mpNNK8H935nRo76Hn1Yb+qZii2GkvCfouy2IWMMOT+HKVGAV2+o= X-Received: by 2002:a63:1e0e:: with SMTP id e14mr388190pge.5.1634749965551; Wed, 20 Oct 2021 10:12:45 -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: From: Dan Williams Date: Wed, 20 Oct 2021 10:12:35 -0700 Message-ID: Subject: Re: [PATCH v1 2/2] mm: remove extra ZONE_DEVICE struct page refcount To: Joao Martins Cc: Jason Gunthorpe , 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-Server: rspam04 X-Rspamd-Queue-Id: B67A14002092 X-Stat-Signature: bzrd14se6o3xyhdhs7j8oinpjygcuoh6 Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=intel-com.20210112.gappssmtp.com header.s=20210112 header.b=gXp+nm6K; spf=none (imf18.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.210.173) smtp.mailfrom=dan.j.williams@intel.com; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none) X-HE-Tag: 1634749963-512196 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, Oct 20, 2021 at 10:09 AM Joao Martins wrote: > > On 10/19/21 20:21, Dan Williams wrote: > > 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. > >> > > I'll go do that. Meanwhile, I'll wait a couple days for Dan to review the > dax subsystem patches (6 & 7), or otherwise send them over. > > >>> 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. > > > I am slightly confused by this comment -- the status quo is what we are > questioning here -- And we talked about changing that in the past too > (thread below), that longterm-gup-fast was an oversight that that commit > was only applicable to fsdax. [Maybe this is just my english confusion] No, you have it correct. However that "regression" has gone unnoticed, so unless there is data showing that gup-fast on device-dax is critical for longterm page pinning workflows I'm ok for longterm to continue to trigger gup-slow.