linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Jan Kara <jack@suse.cz>
Cc: "Michal Hocko" <mhocko@suse.com>,
	kvm@vger.kernel.org,
	"Linux Doc Mailing List" <linux-doc@vger.kernel.org>,
	"David Airlie" <airlied@linux.ie>,
	"Dave Chinner" <david@fromorbit.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Linux MM" <linux-mm@kvack.org>,
	"Paul Mackerras" <paulus@samba.org>,
	"open list:KERNEL SELFTEST FRAMEWORK"
	<linux-kselftest@vger.kernel.org>,
	"Ira Weiny" <ira.weiny@intel.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	linux-rdma@vger.kernel.org,
	"Christoph Hellwig" <hch@infradead.org>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	"Björn Töpel" <bjorn.topel@intel.com>,
	"open list:DMA BUFFER SHARING FRAMEWORK"
	<linux-media@vger.kernel.org>, "Shuah Khan" <shuah@kernel.org>,
	"John Hubbard" <jhubbard@nvidia.com>,
	linux-block@vger.kernel.org, "Jérôme Glisse" <jglisse@redhat.com>,
	"Al Viro" <viro@zeniv.linux.org.uk>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	bpf <bpf@vger.kernel.org>,
	"Magnus Karlsson" <magnus.karlsson@intel.com>,
	"Jens Axboe" <axboe@kernel.dk>, netdev <netdev@vger.kernel.org>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	linux-fsdevel@vger.kernel.org,
	"Andrew Morton" <akpm@linux-foundation.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	"David S . Miller" <davem@davemloft.net>,
	"Mike Kravetz" <mike.kravetz@oracle.com>
Subject: Re: [PATCH v3 00/23] mm/gup: track dma-pinned pages: FOLL_PIN, FOLL_LONGTERM
Date: Wed, 13 Nov 2019 12:43:11 +0100	[thread overview]
Message-ID: <20191113114311.GP23790@phenom.ffwll.local> (raw)
In-Reply-To: <20191113101210.GD6367@quack2.suse.cz>

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

  reply	other threads:[~2019-11-13 11:46 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-12  0:06 [PATCH v3 00/23] mm/gup: track dma-pinned pages: FOLL_PIN, FOLL_LONGTERM John Hubbard
2019-11-12  0:06 ` [PATCH v3 01/23] mm/gup: pass flags arg to __gup_device_* functions John Hubbard
2019-11-12  0:06 ` [PATCH v3 02/23] mm/gup: factor out duplicate code from four routines John Hubbard
2019-11-12  0:06 ` [PATCH v3 03/23] mm/gup: move try_get_compound_head() to top, fix minor issues John Hubbard
2019-11-12  0:06 ` [PATCH v3 04/23] mm: devmap: refactor 1-based refcounting for ZONE_DEVICE pages John Hubbard
2019-11-12  0:06 ` [PATCH v3 05/23] goldish_pipe: rename local pin_user_pages() routine John Hubbard
2019-11-12  0:06 ` [PATCH v3 06/23] IB/umem: use get_user_pages_fast() to pin DMA pages John Hubbard
2019-11-12  0:06 ` [PATCH v3 07/23] media/v4l2-core: set pages dirty upon releasing DMA buffers John Hubbard
2019-11-12  0:06 ` [PATCH v3 08/23] vfio, mm: fix get_user_pages_remote() and FOLL_LONGTERM John Hubbard
2019-11-12 20:43   ` Jason Gunthorpe
2019-11-12 22:42     ` John Hubbard
2019-11-12 22:45       ` Dan Williams
2019-11-12 23:17         ` John Hubbard
2019-11-12 23:42         ` Jason Gunthorpe
2019-11-13  0:58           ` Dan Williams
2019-11-13  1:08             ` John Hubbard
2019-11-13  1:35               ` Dan Williams
2019-11-13  2:09                 ` John Hubbard
2019-11-12 21:57   ` Dan Williams
2019-11-12 22:24     ` John Hubbard
2019-11-12 22:43       ` Dan Williams
2019-11-12 23:08         ` John Hubbard
2019-11-12 23:14           ` Dan Williams
2019-11-12 23:29             ` John Hubbard
2019-11-12  0:06 ` [PATCH v3 09/23] mm/gup: introduce pin_user_pages*() and FOLL_PIN John Hubbard
2019-11-12  6:51   ` Mike Rapoport
2019-11-12  0:06 ` [PATCH v3 10/23] goldish_pipe: convert to pin_user_pages() and put_user_page() John Hubbard
2019-11-12  0:06 ` [PATCH v3 11/23] IB/{core, hw, umem}: set FOLL_PIN, FOLL_LONGTERM via pin_longterm_pages*() John Hubbard
2019-11-12 20:44   ` [PATCH v3 11/23] IB/{core,hw,umem}: " Jason Gunthorpe
2019-11-12 21:14     ` John Hubbard
2019-11-12  0:06 ` [PATCH v3 12/23] mm/process_vm_access: set FOLL_PIN via pin_user_pages_remote() John Hubbard
2019-11-12  0:06 ` [PATCH v3 13/23] drm/via: set FOLL_PIN via pin_user_pages_fast() John Hubbard
2019-11-12  0:06 ` [PATCH v3 14/23] fs/io_uring: set FOLL_PIN via pin_user_pages() John Hubbard
2019-11-12  0:06 ` [PATCH v3 15/23] net/xdp: " John Hubbard
2019-11-12  0:06 ` [PATCH v3 16/23] mm/gup: track FOLL_PIN pages John Hubbard
2019-11-12  0:06 ` [PATCH v3 17/23] media/v4l2-core: pin_longterm_pages (FOLL_PIN) and put_user_page() conversion John Hubbard
2019-11-12  0:06 ` [PATCH v3 18/23] vfio, mm: " John Hubbard
2019-11-12  0:06 ` [PATCH v3 19/23] powerpc: book3s64: convert to pin_longterm_pages() and put_user_page() John Hubbard
2019-11-12  0:06 ` [PATCH v3 20/23] mm/gup_benchmark: use proper FOLL_WRITE flags instead of hard-coding "1" John Hubbard
2019-11-12  0:06 ` [PATCH v3 21/23] mm/gup_benchmark: support pin_user_pages() and related calls John Hubbard
2019-11-12  0:06 ` [PATCH v3 22/23] selftests/vm: run_vmtests: invoke gup_benchmark with basic FOLL_PIN coverage John Hubbard
2019-11-12  0:07 ` [PATCH v3 23/23] mm/gup: remove support for gup(FOLL_LONGTERM) John Hubbard
2019-11-12 20:38 ` [PATCH v3 00/23] mm/gup: track dma-pinned pages: FOLL_PIN, FOLL_LONGTERM Jason Gunthorpe
2019-11-12 21:10   ` John Hubbard
2019-11-13  8:22     ` Daniel Vetter
2019-11-13  9:02       ` John Hubbard
2019-11-13 10:12         ` Jan Kara
2019-11-13 11:43           ` Daniel Vetter [this message]
2019-11-13 20:28             ` John Hubbard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191113114311.GP23790@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=airlied@linux.ie \
    --cc=akpm@linux-foundation.org \
    --cc=alex.williamson@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=bjorn.topel@intel.com \
    --cc=bpf@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=davem@davemloft.net \
    --cc=david@fromorbit.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@infradead.org \
    --cc=ira.weiny@intel.com \
    --cc=jack@suse.cz \
    --cc=jgg@ziepe.ca \
    --cc=jglisse@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=magnus.karlsson@intel.com \
    --cc=mchehab@kernel.org \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=netdev@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=shuah@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).