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=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 8DC11C17442 for ; Wed, 13 Nov 2019 11:43:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4866C2245A for ; Wed, 13 Nov 2019 11:43:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="C0Dbe7TC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4866C2245A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D0AAB6B0005; Wed, 13 Nov 2019 06:43:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C94276B0006; Wed, 13 Nov 2019 06:43:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B0EFA6B0007; Wed, 13 Nov 2019 06:43:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0072.hostedemail.com [216.40.44.72]) by kanga.kvack.org (Postfix) with ESMTP id 945586B0005 for ; Wed, 13 Nov 2019 06:43:17 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 0D0258249980 for ; Wed, 13 Nov 2019 11:43:17 +0000 (UTC) X-FDA: 76151068434.07.hate39_39a414c336022 X-HE-Tag: hate39_39a414c336022 X-Filterd-Recvd-Size: 8950 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Wed, 13 Nov 2019 11:43:15 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id b18so493980wrj.8 for ; Wed, 13 Nov 2019 03:43:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=NWmx5zlrVzI636UV5zn7jwNNYyPpT2kzazOSeqZFCPQ=; b=C0Dbe7TCduZqSim4I/9b7E74bGQO34GH/iKoO+dE+3EHLfWv1lLPGbvorBCoaRGMDb 48v7HTSQHP1LaVgvLNGy/yOxyJTlvTeKuq2CZR/Q7GIgmnQIbkvYhHi8TV/Ec+0WSA8P awH+k+k5IQBNK5RO6uqKbJl7dFmz19ED4sy2I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=NWmx5zlrVzI636UV5zn7jwNNYyPpT2kzazOSeqZFCPQ=; b=NAkyaUhi1pwazBteGHTNjq1peh8Y+5l4WvyP+puh9WeR9SVJMLr7ChHoLqbP9WwDsg f/1zBFixZUg/iNzFni/iPzW0AnBJo6h22j0IUJeeeq2SLRnBB36J2CpUweMo4k9sRooN hfT+his9D/53zxCaxvWB/01C3n80G5OPwJLSvV/BgDf2AcYbXlE5RY4/6XBhUtQzvmaX Y/K/G1xueJWEfgWx1Yd3IoYTbCHobqLlyU2h3HaHJuGe5lc51tjBHUBegBAFvV3YXobU HgF02nDXoUYXjWzrxnKCUlssRCXVnq56cVZE2IosNAvthtmpXyxe1Dg18wct+mDKGPtx 2rSg== X-Gm-Message-State: APjAAAULX/HG4ChNcDap9W7I9gKVWHI1QQf6M1xVdBpWTINUIJdrEc7g RBgLZ9TJv88orE7XBgNfB626ww== X-Google-Smtp-Source: APXvYqw4ALVmGTh9KFISsJCvLVpFEzXuyu2WMWEkcAdM7khXUlUWKA93QR1nKFP8k/o5YdLFIE0ItA== X-Received: by 2002:a5d:50ce:: with SMTP id f14mr2625324wrt.219.1573645394576; Wed, 13 Nov 2019 03:43:14 -0800 (PST) Received: from phenom.ffwll.local (212-51-149-96.fiber7.init7.net. [212.51.149.96]) by smtp.gmail.com with ESMTPSA id w4sm2544060wrs.1.2019.11.13.03.43.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Nov 2019 03:43:13 -0800 (PST) Date: Wed, 13 Nov 2019 12:43:11 +0100 From: Daniel Vetter To: Jan Kara Cc: John Hubbard , Daniel Vetter , Jason Gunthorpe , Andrew Morton , Al Viro , Alex Williamson , Benjamin Herrenschmidt , =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= , Christoph Hellwig , Dan Williams , Dave Chinner , David Airlie , "David S . Miller" , Ira Weiny , Jens Axboe , Jonathan Corbet , =?iso-8859-1?B?Suly9G1l?= Glisse , Magnus Karlsson , Mauro Carvalho Chehab , Michael Ellerman , Michal Hocko , Mike Kravetz , Paul Mackerras , Shuah Khan , Vlastimil Babka , bpf , dri-devel , kvm@vger.kernel.org, linux-block@vger.kernel.org, Linux Doc Mailing List , linux-fsdevel@vger.kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" , "open list:DMA BUFFER SHARING FRAMEWORK" , linux-rdma@vger.kernel.org, linuxppc-dev , netdev , Linux MM , LKML Subject: Re: [PATCH v3 00/23] mm/gup: track dma-pinned pages: FOLL_PIN, FOLL_LONGTERM Message-ID: <20191113114311.GP23790@phenom.ffwll.local> Mail-Followup-To: Jan Kara , John Hubbard , Jason Gunthorpe , Andrew Morton , Al Viro , Alex Williamson , Benjamin Herrenschmidt , =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= , Christoph Hellwig , Dan Williams , Dave Chinner , David Airlie , "David S . Miller" , Ira Weiny , Jens Axboe , Jonathan Corbet , =?iso-8859-1?B?Suly9G1l?= Glisse , Magnus Karlsson , Mauro Carvalho Chehab , Michael Ellerman , Michal Hocko , Mike Kravetz , Paul Mackerras , Shuah Khan , Vlastimil Babka , bpf , dri-devel , kvm@vger.kernel.org, linux-block@vger.kernel.org, Linux Doc Mailing List , linux-fsdevel@vger.kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" , "open list:DMA BUFFER SHARING FRAMEWORK" , linux-rdma@vger.kernel.org, linuxppc-dev , netdev , Linux MM , LKML References: <20191112000700.3455038-1-jhubbard@nvidia.com> <20191112203802.GD5584@ziepe.ca> <02fa935c-3469-b766-b691-5660084b60b9@nvidia.com> <7b671bf9-4d94-f2cc-8453-863acd5a1115@nvidia.com> <20191113101210.GD6367@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191113101210.GD6367@quack2.suse.cz> X-Operating-System: Linux phenom 5.2.0-3-amd64 User-Agent: Mutt/1.12.2 (2019-09-21) 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, Nov 13, 2019 at 11:12:10AM +0100, Jan Kara wrote: > On Wed 13-11-19 01:02:02, John Hubbard wrote: > > On 11/13/19 12:22 AM, Daniel Vetter wrote: > > ... > > > > > Why are we doing this? I think things got confused here someplace, as > > > > > > > > > > > > Because: > > > > > > > > a) These need put_page() calls, and > > > > > > > > b) there is no put_pages() call, but there is a release_pages() call that > > > > is, arguably, what put_pages() would be. > > > > > > > > > > > > > the comment still says: > > > > > > > > > > /** > > > > > * put_user_page() - release a gup-pinned page > > > > > * @page: pointer to page to be released > > > > > * > > > > > * Pages that were pinned via get_user_pages*() must be released via > > > > > * either put_user_page(), or one of the put_user_pages*() routines > > > > > * below. > > > > > > > > > > > > Ohhh, I missed those comments. They need to all be changed over to > > > > say "pages that were pinned via pin_user_pages*() or > > > > pin_longterm_pages*() must be released via put_user_page*()." > > > > > > > > The get_user_pages*() pages must still be released via put_page. > > > > > > > > The churn is due to a fairly significant change in strategy, whis > > > > is: instead of changing all get_user_pages*() sites to call > > > > put_user_page(), change selected sites to call pin_user_pages*() or > > > > pin_longterm_pages*(), plus put_user_page(). > > > > > > Can't we call this unpin_user_page then, for some symmetry? Or is that > > > even more churn? > > > > > > Looking from afar the naming here seems really confusing. > > > > > > That look from afar is valuable, because I'm too close to the problem to see > > how the naming looks. :) > > > > unpin_user_page() sounds symmetrical. It's true that it would cause more > > churn (which is why I started off with a proposal that avoids changing the > > names of put_user_page*() APIs). But OTOH, the amount of churn is proportional > > to the change in direction here, and it's really only 10 or 20 lines changed, > > in the end. > > > > So I'm open to changing to that naming. It would be nice to hear what others > > prefer, too... > > FWIW I'd find unpin_user_page() also better than put_user_page() as a > counterpart to pin_user_pages(). One more point from afar on pin/unpin: We use that a lot in graphics for permanently pinned graphics buffer objects. Which really only should be used for scanout. So at least graphics folks should have an appropriate mindset and try to make sure we don't overuse this stuff. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch