From: Ira Weiny <ira.weiny@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: "John Hubbard" <jhubbard@nvidia.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Al Viro" <viro@zeniv.linux.org.uk>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
"Björn Töpel" <bjorn.topel@intel.com>,
"Christoph Hellwig" <hch@infradead.org>,
"Dan Williams" <dan.j.williams@intel.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Dave Chinner" <david@fromorbit.com>,
"David Airlie" <airlied@linux.ie>,
"David S . Miller" <davem@davemloft.net>,
"Jason Gunthorpe" <jgg@ziepe.ca>, "Jens Axboe" <axboe@kernel.dk>,
"Jonathan Corbet" <corbet@lwn.net>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Magnus Karlsson" <magnus.karlsson@intel.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Michael Ellerman" <mpe@ellerman.id.au>,
"Michal Hocko" <mhocko@suse.com>,
"Mike Kravetz" <mike.kravetz@oracle.com>,
"Paul Mackerras" <paulus@samba.org>,
"Shuah Khan" <shuah@kernel.org>,
"Vlastimil Babka" <vbabka@suse.cz>,
bpf@vger.kernel.org, dri-devel@lists.freedesktop.org,
kvm@vger.kernel.org, linux-block@vger.kernel.org,
linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-media@vger.kernel.org,
linux-rdma@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
netdev@vger.kernel.org, linux-mm@kvack.org,
LKML <linux-kernel@vger.kernel.org>,
"Mike Rapoport" <rppt@linux.ibm.com>
Subject: Re: [PATCH v4 09/23] mm/gup: introduce pin_user_pages*() and FOLL_PIN
Date: Wed, 13 Nov 2019 10:31:38 -0800 [thread overview]
Message-ID: <20191113183137.GA12699@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <20191113104308.GE6367@quack2.suse.cz>
> > +/**
> > + * pin_user_pages_fast() - pin user pages in memory without taking locks
> > + *
> > + * Nearly the same as get_user_pages_fast(), except that FOLL_PIN is set. See
> > + * get_user_pages_fast() for documentation on the function arguments, because
> > + * the arguments here are identical.
> > + *
> > + * FOLL_PIN means that the pages must be released via put_user_page(). Please
> > + * see Documentation/vm/pin_user_pages.rst for further details.
> > + *
> > + * This is intended for Case 1 (DIO) in Documentation/vm/pin_user_pages.rst. It
> > + * is NOT intended for Case 2 (RDMA: long-term pins).
> > + */
> > +int pin_user_pages_fast(unsigned long start, int nr_pages,
> > + unsigned int gup_flags, struct page **pages)
> > +{
> > + /* FOLL_GET and FOLL_PIN are mutually exclusive. */
> > + if (WARN_ON_ONCE(gup_flags & FOLL_GET))
> > + return -EINVAL;
> > +
> > + gup_flags |= FOLL_PIN;
> > + return internal_get_user_pages_fast(start, nr_pages, gup_flags, pages);
> > +}
> > +EXPORT_SYMBOL_GPL(pin_user_pages_fast);
>
> I was somewhat wondering about the number of functions you add here. So we
> have:
>
> pin_user_pages()
> pin_user_pages_fast()
> pin_user_pages_remote()
>
> and then longterm variants:
>
> pin_longterm_pages()
> pin_longterm_pages_fast()
> pin_longterm_pages_remote()
>
> and obviously we have gup like:
> get_user_pages()
> get_user_pages_fast()
> get_user_pages_remote()
> ... and some other gup variants ...
>
> I think we really should have pin_* vs get_* variants as they are very
> different in terms of guarantees and after conversion, any use of get_*
> variant in non-mm code should be closely scrutinized. OTOH pin_longterm_*
> don't look *that* useful to me and just using pin_* instead with
> FOLL_LONGTERM flag would look OK to me and somewhat reduce the number of
> functions which is already large enough? What do people think? I don't feel
> too strongly about this but wanted to bring this up.
I'm a bit concerned with the function explosion myself. I think what you
suggest is a happy medium. So I'd be ok with that.
Ira
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: "Michal Hocko" <mhocko@suse.com>,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
"David Airlie" <airlied@linux.ie>,
"Dave Chinner" <david@fromorbit.com>,
dri-devel@lists.freedesktop.org,
LKML <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org, "Paul Mackerras" <paulus@samba.org>,
linux-kselftest@vger.kernel.org, "Shuah Khan" <shuah@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
linux-rdma@vger.kernel.org, "Mike Rapoport" <rppt@linux.ibm.com>,
"Christoph Hellwig" <hch@infradead.org>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"Vlastimil Babka" <vbabka@suse.cz>,
"Björn Töpel" <bjorn.topel@intel.com>,
linux-media@vger.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@vger.kernel.org,
"Magnus Karlsson" <magnus.karlsson@intel.com>,
"Jens Axboe" <axboe@kernel.dk>,
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@lists.ozlabs.org,
"David S . Miller" <davem@davemloft.net>,
"Mike Kravetz" <mike.kravetz@oracle.com>
Subject: Re: [PATCH v4 09/23] mm/gup: introduce pin_user_pages*() and FOLL_PIN
Date: Wed, 13 Nov 2019 10:31:38 -0800 [thread overview]
Message-ID: <20191113183137.GA12699@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <20191113104308.GE6367@quack2.suse.cz>
> > +/**
> > + * pin_user_pages_fast() - pin user pages in memory without taking locks
> > + *
> > + * Nearly the same as get_user_pages_fast(), except that FOLL_PIN is set. See
> > + * get_user_pages_fast() for documentation on the function arguments, because
> > + * the arguments here are identical.
> > + *
> > + * FOLL_PIN means that the pages must be released via put_user_page(). Please
> > + * see Documentation/vm/pin_user_pages.rst for further details.
> > + *
> > + * This is intended for Case 1 (DIO) in Documentation/vm/pin_user_pages.rst. It
> > + * is NOT intended for Case 2 (RDMA: long-term pins).
> > + */
> > +int pin_user_pages_fast(unsigned long start, int nr_pages,
> > + unsigned int gup_flags, struct page **pages)
> > +{
> > + /* FOLL_GET and FOLL_PIN are mutually exclusive. */
> > + if (WARN_ON_ONCE(gup_flags & FOLL_GET))
> > + return -EINVAL;
> > +
> > + gup_flags |= FOLL_PIN;
> > + return internal_get_user_pages_fast(start, nr_pages, gup_flags, pages);
> > +}
> > +EXPORT_SYMBOL_GPL(pin_user_pages_fast);
>
> I was somewhat wondering about the number of functions you add here. So we
> have:
>
> pin_user_pages()
> pin_user_pages_fast()
> pin_user_pages_remote()
>
> and then longterm variants:
>
> pin_longterm_pages()
> pin_longterm_pages_fast()
> pin_longterm_pages_remote()
>
> and obviously we have gup like:
> get_user_pages()
> get_user_pages_fast()
> get_user_pages_remote()
> ... and some other gup variants ...
>
> I think we really should have pin_* vs get_* variants as they are very
> different in terms of guarantees and after conversion, any use of get_*
> variant in non-mm code should be closely scrutinized. OTOH pin_longterm_*
> don't look *that* useful to me and just using pin_* instead with
> FOLL_LONGTERM flag would look OK to me and somewhat reduce the number of
> functions which is already large enough? What do people think? I don't feel
> too strongly about this but wanted to bring this up.
I'm a bit concerned with the function explosion myself. I think what you
suggest is a happy medium. So I'd be ok with that.
Ira
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: "John Hubbard" <jhubbard@nvidia.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Al Viro" <viro@zeniv.linux.org.uk>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
"Björn Töpel" <bjorn.topel@intel.com>,
"Christoph Hellwig" <hch@infradead.org>,
"Dan Williams" <dan.j.williams@intel.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Dave Chinner" <david@fromorbit.com>,
"David Airlie" <airlied@linux.ie>,
"David S . Miller" <davem@davemloft.net>,
"Jason Gunthorpe" <jgg@ziepe.ca>, "Jens Axboe" <axboe@kernel.dk>,
"Jonathan Corbet" <corbet@lwn.net>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Magnus Karlsson" <magnus.karlsson@intel.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Michael Ellerman" <mpe@eller>
Subject: Re: [PATCH v4 09/23] mm/gup: introduce pin_user_pages*() and FOLL_PIN
Date: Wed, 13 Nov 2019 10:31:38 -0800 [thread overview]
Message-ID: <20191113183137.GA12699@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <20191113104308.GE6367@quack2.suse.cz>
> > +/**
> > + * pin_user_pages_fast() - pin user pages in memory without taking locks
> > + *
> > + * Nearly the same as get_user_pages_fast(), except that FOLL_PIN is set. See
> > + * get_user_pages_fast() for documentation on the function arguments, because
> > + * the arguments here are identical.
> > + *
> > + * FOLL_PIN means that the pages must be released via put_user_page(). Please
> > + * see Documentation/vm/pin_user_pages.rst for further details.
> > + *
> > + * This is intended for Case 1 (DIO) in Documentation/vm/pin_user_pages.rst. It
> > + * is NOT intended for Case 2 (RDMA: long-term pins).
> > + */
> > +int pin_user_pages_fast(unsigned long start, int nr_pages,
> > + unsigned int gup_flags, struct page **pages)
> > +{
> > + /* FOLL_GET and FOLL_PIN are mutually exclusive. */
> > + if (WARN_ON_ONCE(gup_flags & FOLL_GET))
> > + return -EINVAL;
> > +
> > + gup_flags |= FOLL_PIN;
> > + return internal_get_user_pages_fast(start, nr_pages, gup_flags, pages);
> > +}
> > +EXPORT_SYMBOL_GPL(pin_user_pages_fast);
>
> I was somewhat wondering about the number of functions you add here. So we
> have:
>
> pin_user_pages()
> pin_user_pages_fast()
> pin_user_pages_remote()
>
> and then longterm variants:
>
> pin_longterm_pages()
> pin_longterm_pages_fast()
> pin_longterm_pages_remote()
>
> and obviously we have gup like:
> get_user_pages()
> get_user_pages_fast()
> get_user_pages_remote()
> ... and some other gup variants ...
>
> I think we really should have pin_* vs get_* variants as they are very
> different in terms of guarantees and after conversion, any use of get_*
> variant in non-mm code should be closely scrutinized. OTOH pin_longterm_*
> don't look *that* useful to me and just using pin_* instead with
> FOLL_LONGTERM flag would look OK to me and somewhat reduce the number of
> functions which is already large enough? What do people think? I don't feel
> too strongly about this but wanted to bring this up.
I'm a bit concerned with the function explosion myself. I think what you
suggest is a happy medium. So I'd be ok with that.
Ira
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: "Michal Hocko" <mhocko@suse.com>,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
"David Airlie" <airlied@linux.ie>,
"Dave Chinner" <david@fromorbit.com>,
dri-devel@lists.freedesktop.org,
LKML <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org, "Paul Mackerras" <paulus@samba.org>,
linux-kselftest@vger.kernel.org, "Shuah Khan" <shuah@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
linux-rdma@vger.kernel.org,
"Michael Ellerman" <mpe@ellerman.id.au>,
"Mike Rapoport" <rppt@linux.ibm.com>,
"Christoph Hellwig" <hch@infradead.org>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"Vlastimil Babka" <vbabka@suse.cz>,
"Björn Töpel" <bjorn.topel@intel.com>,
linux-media@vger.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@vger.kernel.org,
"Magnus Karlsson" <magnus.karlsson@intel.com>,
"Jens Axboe" <axboe@kernel.dk>,
netdev@vger.kernel.org,
"Alex Williamson" <alex.williamson@redhat.com>,
linux-fsdevel@vger.kernel.org,
"Andrew Morton" <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
"David S . Miller" <davem@davemloft.net>,
"Mike Kravetz" <mike.kravetz@oracle.com>
Subject: Re: [PATCH v4 09/23] mm/gup: introduce pin_user_pages*() and FOLL_PIN
Date: Wed, 13 Nov 2019 10:31:38 -0800 [thread overview]
Message-ID: <20191113183137.GA12699@iweiny-DESK2.sc.intel.com> (raw)
Message-ID: <20191113183138.jr7C1xfEWrfjFd4KGB-BixQL0YAXz2AMVdMFp-mYZxk@z> (raw)
In-Reply-To: <20191113104308.GE6367@quack2.suse.cz>
> > +/**
> > + * pin_user_pages_fast() - pin user pages in memory without taking locks
> > + *
> > + * Nearly the same as get_user_pages_fast(), except that FOLL_PIN is set. See
> > + * get_user_pages_fast() for documentation on the function arguments, because
> > + * the arguments here are identical.
> > + *
> > + * FOLL_PIN means that the pages must be released via put_user_page(). Please
> > + * see Documentation/vm/pin_user_pages.rst for further details.
> > + *
> > + * This is intended for Case 1 (DIO) in Documentation/vm/pin_user_pages.rst. It
> > + * is NOT intended for Case 2 (RDMA: long-term pins).
> > + */
> > +int pin_user_pages_fast(unsigned long start, int nr_pages,
> > + unsigned int gup_flags, struct page **pages)
> > +{
> > + /* FOLL_GET and FOLL_PIN are mutually exclusive. */
> > + if (WARN_ON_ONCE(gup_flags & FOLL_GET))
> > + return -EINVAL;
> > +
> > + gup_flags |= FOLL_PIN;
> > + return internal_get_user_pages_fast(start, nr_pages, gup_flags, pages);
> > +}
> > +EXPORT_SYMBOL_GPL(pin_user_pages_fast);
>
> I was somewhat wondering about the number of functions you add here. So we
> have:
>
> pin_user_pages()
> pin_user_pages_fast()
> pin_user_pages_remote()
>
> and then longterm variants:
>
> pin_longterm_pages()
> pin_longterm_pages_fast()
> pin_longterm_pages_remote()
>
> and obviously we have gup like:
> get_user_pages()
> get_user_pages_fast()
> get_user_pages_remote()
> ... and some other gup variants ...
>
> I think we really should have pin_* vs get_* variants as they are very
> different in terms of guarantees and after conversion, any use of get_*
> variant in non-mm code should be closely scrutinized. OTOH pin_longterm_*
> don't look *that* useful to me and just using pin_* instead with
> FOLL_LONGTERM flag would look OK to me and somewhat reduce the number of
> functions which is already large enough? What do people think? I don't feel
> too strongly about this but wanted to bring this up.
I'm a bit concerned with the function explosion myself. I think what you
suggest is a happy medium. So I'd be ok with that.
Ira
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-11-13 18:31 UTC|newest]
Thread overview: 216+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-13 4:26 [PATCH v4 00/23] mm/gup: track dma-pinned pages: FOLL_PIN, FOLL_LONGTERM John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` [PATCH v4 01/23] mm/gup: pass flags arg to __gup_device_* functions John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 10:50 ` Jan Kara
2019-11-13 10:50 ` Jan Kara
2019-11-13 10:50 ` Jan Kara
2019-11-13 10:50 ` Jan Kara
2019-11-13 4:26 ` [PATCH v4 02/23] mm/gup: factor out duplicate code from four routines John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 11:15 ` Jan Kara
2019-11-13 11:15 ` Jan Kara
2019-11-13 11:15 ` Jan Kara
2019-11-13 11:15 ` Jan Kara
2019-11-13 23:12 ` John Hubbard
2019-11-13 23:12 ` John Hubbard
2019-11-13 23:12 ` John Hubbard
2019-11-13 23:12 ` John Hubbard
2019-11-13 4:26 ` [PATCH v4 03/23] mm/gup: move try_get_compound_head() to top, fix minor issues John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 10:50 ` Jan Kara
2019-11-13 10:50 ` Jan Kara
2019-11-13 10:50 ` Jan Kara
2019-11-13 10:50 ` Jan Kara
2019-11-13 18:38 ` Ira Weiny
2019-11-13 18:38 ` Ira Weiny
2019-11-13 18:38 ` Ira Weiny
2019-11-13 18:38 ` Ira Weiny
2019-11-13 4:26 ` [PATCH v4 04/23] mm: devmap: refactor 1-based refcounting for ZONE_DEVICE pages John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 10:49 ` Jan Kara
2019-11-13 10:49 ` Jan Kara
2019-11-13 10:49 ` Jan Kara
2019-11-13 10:49 ` Jan Kara
2019-11-13 19:09 ` Jerome Glisse
2019-11-13 19:09 ` Jerome Glisse
2019-11-13 19:09 ` Jerome Glisse
2019-11-13 19:09 ` Jerome Glisse
2019-11-13 19:23 ` Dan Williams
2019-11-13 19:23 ` Dan Williams
2019-11-13 19:23 ` Dan Williams
2019-11-13 19:23 ` Dan Williams
2019-11-13 22:00 ` Dan Williams
2019-11-13 22:00 ` Dan Williams
2019-11-13 22:00 ` Dan Williams
2019-11-13 22:00 ` Dan Williams
2019-11-13 22:46 ` John Hubbard
2019-11-13 22:46 ` John Hubbard
2019-11-13 22:46 ` John Hubbard
2019-11-13 22:46 ` John Hubbard
2019-11-13 22:55 ` Dan Williams
2019-11-13 22:55 ` Dan Williams
2019-11-13 22:55 ` Dan Williams
2019-11-13 22:55 ` Dan Williams
2019-11-13 22:56 ` John Hubbard
2019-11-13 22:56 ` John Hubbard
2019-11-13 22:56 ` John Hubbard
2019-11-13 22:56 ` John Hubbard
2019-11-13 23:03 ` Jerome Glisse
2019-11-13 23:03 ` Jerome Glisse
2019-11-13 23:03 ` Jerome Glisse
2019-11-13 23:03 ` Jerome Glisse
2019-11-13 4:26 ` [PATCH v4 05/23] goldish_pipe: rename local pin_user_pages() routine John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` [PATCH v4 06/23] IB/umem: use get_user_pages_fast() to pin DMA pages John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` [PATCH v4 07/23] media/v4l2-core: set pages dirty upon releasing DMA buffers John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` [PATCH v4 08/23] vfio, mm: fix get_user_pages_remote() and FOLL_LONGTERM John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 13:02 ` Jason Gunthorpe
2019-11-13 13:02 ` Jason Gunthorpe
2019-11-13 13:02 ` Jason Gunthorpe
2019-11-13 13:02 ` Jason Gunthorpe
2019-11-13 19:17 ` Ira Weiny
2019-11-13 19:17 ` Ira Weiny
2019-11-13 19:17 ` Ira Weiny
2019-11-13 19:17 ` Ira Weiny
2019-11-13 20:19 ` John Hubbard
2019-11-13 20:19 ` John Hubbard
2019-11-13 20:19 ` John Hubbard
2019-11-13 20:19 ` John Hubbard
2019-11-13 18:47 ` Ira Weiny
2019-11-13 18:47 ` Ira Weiny
2019-11-13 18:47 ` Ira Weiny
2019-11-13 18:47 ` Ira Weiny
2019-11-13 4:26 ` [PATCH v4 09/23] mm/gup: introduce pin_user_pages*() and FOLL_PIN John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 10:43 ` Jan Kara
2019-11-13 10:43 ` Jan Kara
2019-11-13 10:43 ` Jan Kara
2019-11-13 10:43 ` Jan Kara
2019-11-13 18:31 ` Ira Weiny [this message]
2019-11-13 18:31 ` Ira Weiny
2019-11-13 18:31 ` Ira Weiny
2019-11-13 18:31 ` Ira Weiny
2019-11-13 18:45 ` Dan Williams
2019-11-13 18:45 ` Dan Williams
2019-11-13 18:45 ` Dan Williams
2019-11-13 18:45 ` Dan Williams
2019-11-13 23:22 ` John Hubbard
2019-11-13 23:22 ` John Hubbard
2019-11-13 23:22 ` John Hubbard
2019-11-13 23:22 ` John Hubbard
2019-11-14 6:08 ` John Hubbard
2019-11-14 6:08 ` John Hubbard
2019-11-14 6:08 ` John Hubbard
2019-11-14 6:08 ` John Hubbard
2019-11-13 18:59 ` Ira Weiny
2019-11-13 18:59 ` Ira Weiny
2019-11-13 18:59 ` Ira Weiny
2019-11-13 18:59 ` Ira Weiny
2019-11-13 20:24 ` John Hubbard
2019-11-13 20:24 ` John Hubbard
2019-11-13 20:24 ` John Hubbard
2019-11-13 20:24 ` John Hubbard
2019-11-13 4:26 ` [PATCH v4 10/23] goldish_pipe: convert to pin_user_pages() and put_user_page() John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` [PATCH v4 11/23] IB/{core,hw,umem}: set FOLL_PIN, FOLL_LONGTERM via pin_longterm_pages*() John Hubbard
2019-11-13 4:26 ` [PATCH v4 11/23] IB/{core, hw, umem}: " John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` [PATCH v4 12/23] mm/process_vm_access: set FOLL_PIN via pin_user_pages_remote() John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:26 ` John Hubbard
2019-11-13 4:27 ` [PATCH v4 13/23] drm/via: set FOLL_PIN via pin_user_pages_fast() John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` [PATCH v4 14/23] fs/io_uring: set FOLL_PIN via pin_user_pages() John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` [PATCH v4 15/23] net/xdp: " John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` [PATCH v4 16/23] mm/gup: track FOLL_PIN pages John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` [PATCH v4 17/23] media/v4l2-core: pin_longterm_pages (FOLL_PIN) and put_user_page() conversion John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` [PATCH v4 18/23] vfio, mm: " John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` [PATCH v4 19/23] powerpc: book3s64: convert to pin_longterm_pages() and put_user_page() John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` [PATCH v4 20/23] mm/gup_benchmark: use proper FOLL_WRITE flags instead of hard-coding "1" John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 19:01 ` Ira Weiny
2019-11-13 19:01 ` Ira Weiny
2019-11-13 19:01 ` Ira Weiny
2019-11-13 19:01 ` Ira Weiny
2019-11-13 4:27 ` [PATCH v4 21/23] mm/gup_benchmark: support pin_user_pages() and related calls John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 19:03 ` Ira Weiny
2019-11-13 19:03 ` Ira Weiny
2019-11-13 19:03 ` Ira Weiny
2019-11-13 19:03 ` Ira Weiny
2019-11-13 4:27 ` [PATCH v4 22/23] selftests/vm: run_vmtests: invoke gup_benchmark with basic FOLL_PIN coverage John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 19:06 ` Ira Weiny
2019-11-13 19:06 ` Ira Weiny
2019-11-13 19:06 ` Ira Weiny
2019-11-13 19:06 ` Ira Weiny
2019-11-13 4:27 ` [PATCH v4 23/23] mm/gup: remove support for gup(FOLL_LONGTERM) John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 4:27 ` John Hubbard
2019-11-13 19:09 ` Ira Weiny
2019-11-13 19:09 ` Ira Weiny
2019-11-13 19:09 ` Ira Weiny
2019-11-13 19:09 ` Ira Weiny
2019-11-13 23:27 ` John Hubbard
2019-11-13 23:27 ` John Hubbard
2019-11-13 23:27 ` John Hubbard
2019-11-13 23:27 ` John Hubbard
2019-11-13 4:32 ` [PATCH v4 00/23] mm/gup: track dma-pinned pages: FOLL_PIN, FOLL_LONGTERM John Hubbard
2019-11-13 4:32 ` John Hubbard
2019-11-13 4:32 ` John Hubbard
2019-11-13 4:32 ` 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=20191113183137.GA12699@iweiny-DESK2.sc.intel.com \
--to=ira.weiny@intel.com \
--cc=airlied@linux.ie \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=axboe@kernel.dk \
--cc=benh@kernel.crashing.org \
--cc=bjorn.topel@intel.com \
--cc=bpf@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=daniel@ffwll.ch \
--cc=davem@davemloft.net \
--cc=david@fromorbit.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@infradead.org \
--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=mpe@ellerman.id.au \
--cc=netdev@vger.kernel.org \
--cc=paulus@samba.org \
--cc=rppt@linux.ibm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.