From: Jason Gunthorpe <jgg@ziepe.ca>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: akpm@linux-foundation.org, dledford@redhat.com, jack@suse.cz,
willy@infradead.org, ira.weiny@intel.com,
linux-rdma@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/6] mm: make pinned_vm atomic and simplify users
Date: Thu, 7 Feb 2019 13:12:52 -0700 [thread overview]
Message-ID: <20190207201252.GA29842@ziepe.ca> (raw)
In-Reply-To: <20190206175920.31082-1-dave@stgolabs.net>
On Wed, Feb 06, 2019 at 09:59:14AM -0800, Davidlohr Bueso wrote:
> Changes from v2 (https://patchwork.kernel.org/cover/10774255/):
> - Added more reviews for patch 1 and also fixed mm/debug.c to
> use llx insted of lx so gcc doesn't complain.
>
> - Re did patch 3 (qib rdma) such that we still have to take
> mmap_sem as it now uses gup_longterm(). gup_fast() conversion
> remains for patch 2 which is not infiniband.
>
> - Rebased for rdma tree.
>
> Changes from v1 (https://patchwork.kernel.org/cover/10764923/):
> - Converted pinned_vm to atomic64 instead of atomic_long such that
> infiniband need not worry about overflows.
>
> - Rebased patch 1 and added Ira's reviews as well as Parvi's review
> for patch 5 (thanks!).
>
> --------
>
> Hi,
>
> The following patches aim to provide cleanups to users that pin pages
> (mostly infiniband) by converting the counter to atomic -- note that
> Daniel Jordan also has patches[1] for the locked_vm counterpart and vfio.
>
> Apart from removing a source of mmap_sem writer, we benefit in that
> we can get rid of a lot of code that defers work when the lock cannot
> be acquired, as well as drivers avoiding mmap_sem altogether by also
> converting gup to gup_fast() and letting the mm handle it. Users
> that do the gup_longterm() remain of course under at least reader mmap_sem.
>
> Everything has been compile-tested _only_ so I hope I didn't do anything
> too stupid. Please consider for v5.1.
>
> On a similar topic and potential follow up, it would be nice to resurrect
> Peter's VM_PINNED idea in that the broken semantics that occurred after
> bc3e53f682 ("mm: distinguish between mlocked and pinned pages") are still
> present. Also encapsulating internal mm logic via mm[un]pin() instead of
> drivers having to know about internals and playing nice with compaction are
> all wins.
>
> Applies against rdma's for-next branch.
>
> Thanks!
>
> [1] https://lkml.org/lkml/2018/11/5/854
>
> Davidlohr Bueso (6):
> mm: make mm->pinned_vm an atomic64 counter
> drivers/mic/scif: do not use mmap_sem
> drivers/IB,qib: optimize mmap_sem usage
> drivers/IB,hfi1: do not se mmap_sem
> drivers/IB,usnic: reduce scope of mmap_sem
> drivers/IB,core: reduce scope of mmap_sem
The surprise 7th patch was mangled, but I recreated it by hand
Otherwise applied to rdma for-next
Thanks,
Jason
prev parent reply other threads:[~2019-02-07 20:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-06 17:59 [PATCH v3 0/6] mm: make pinned_vm atomic and simplify users Davidlohr Bueso
2019-02-06 17:59 ` [PATCH 1/6] mm: make mm->pinned_vm an atomic64 counter Davidlohr Bueso
2019-02-06 17:59 ` [PATCH 2/6] drivers/mic/scif: do not use mmap_sem Davidlohr Bueso
2019-02-06 17:59 ` [PATCH 3/6] drivers/IB,qib: optimize mmap_sem usage Davidlohr Bueso
2019-02-06 17:59 ` [PATCH 4/6] drivers/IB,hfi1: do not se mmap_sem Davidlohr Bueso
2019-02-06 17:59 ` [PATCH 5/6] drivers/IB,usnic: reduce scope of mmap_sem Davidlohr Bueso
2019-02-06 17:59 ` [PATCH 6/6] drivers/IB,core: " Davidlohr Bueso
2019-02-07 1:31 ` [PATCH 7/6] Documentation/infiniband: update from locked to pinned_vm Davidlohr Bueso
2019-02-12 0:35 ` Weiny, Ira
2019-02-07 20:12 ` Jason Gunthorpe [this message]
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=20190207201252.GA29842@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=akpm@linux-foundation.org \
--cc=dave@stgolabs.net \
--cc=dledford@redhat.com \
--cc=ira.weiny@intel.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=willy@infradead.org \
/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.