On Tue, Feb 23, 2021 at 9:16 AM Joao Martins <joao.m.mart...@oracle.com> wrote:
>
> On 2/23/21 4:44 PM, Dan Williams wrote:
> > On Tue, Feb 23, 2021 at 8:30 AM Joao Martins <joao.m.mart...@oracle.com>
> > wrote:
> >>
> >> On 2/20/21 1:18 AM, Dan Williams wrote:
> >>> On Tue, Dec 8, 2020 at 9:32 AM Joao Martins <joao.m.mart...@oracle.com>
> >>> wrote:
> >>>> Patch 6 - 8: Optimize grabbing/release a page refcount changes given
> >>>> that we
> >>>> are working with compound pages i.e. we do 1 increment/decrement to the
> >>>> head
> >>>> page for a given set of N subpages compared as opposed to N individual
> >>>> writes.
> >>>> {get,pin}_user_pages_fast() for zone_device with compound pagemap
> >>>> consequently
> >>>> improves considerably, and unpin_user_pages() improves as well when
> >>>> passed a
> >>>> set of consecutive pages:
> >>>>
> >>>> before after
> >>>> (get_user_pages_fast 1G;2M page size) ~75k us -> ~3.2k ; ~5.2k us
> >>>> (pin_user_pages_fast 1G;2M page size) ~125k us -> ~3.4k ; ~5.5k us
> >>>
> >>> Compelling!
> >>>
> >>
> >> BTW is there any reason why we don't support pin_user_pages_fast() with
> >> FOLL_LONGTERM for
> >> device-dax?
> >>
> >
> > Good catch.
> >
> > Must have been an oversight of the conversion. FOLL_LONGTERM collides
> > with filesystem operations, but not device-dax.
>
> hmmmm, fwiw, it was unilaterally disabled for any devmap pmd/pud in commit
> 7af75561e171
> ("mm/gup: add FOLL_LONGTERM capability to GUP fast") and I must only assume
> that
> by "DAX pages" the submitter was only referring to fs-dax pages.
Agree, that was an fsdax only assumption. Maybe this went unnoticed
because the primary gup-fast case for direct-I/O was not impacted.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
