similar to: [PATCH] mm/hmm: replace hmm_update with mmu_notifier_range

On Wed, Jul 24, 2019 at 09:05:53AM +0200, Christoph Hellwig wrote: > Looks good: > > Reviewed-by: Christoph Hellwig <hch at lst.de> > > One comment on a related cleanup: > > > list_for_each_entry(mirror, &hmm->mirrors, list) { > > int rc; > > > > - rc = mirror->ops->sync_cpu_device_pagetables(mirror, &update); > > +

Looks good: Reviewed-by: Christoph Hellwig <hch at lst.de> One comment on a related cleanup: > list_for_each_entry(mirror, &hmm->mirrors, list) { > int rc; > > - rc = mirror->ops->sync_cpu_device_pagetables(mirror, &update); > + rc = mirror->ops->sync_cpu_device_pagetables(mirror, nrange); > if (rc) { > - if

On Wed 24-07-19 12:28:58, Jason Gunthorpe wrote: > On Wed, Jul 24, 2019 at 09:05:53AM +0200, Christoph Hellwig wrote: > > Looks good: > > > > Reviewed-by: Christoph Hellwig <hch at lst.de> > > > > One comment on a related cleanup: > > > > > list_for_each_entry(mirror, &hmm->mirrors, list) { > > > int rc; > > >

Here are seven more patches for things I found to clean up. This was based on top of Christoph's seven patches: "hmm_range_fault related fixes and legacy API removal v3". I assume this will go into Jason's tree since there will likely be more HMM changes in this cycle. Changes from v1 to v2: Added AMD GPU to hmm_update removal. Added 2 patches from Christoph. Added 2 patches as

On Wed, Jul 24, 2019 at 07:58:58PM +0200, Michal Hocko wrote: > On Wed 24-07-19 12:28:58, Jason Gunthorpe wrote: > > On Wed, Jul 24, 2019 at 09:05:53AM +0200, Christoph Hellwig wrote: > > > Looks good: > > > > > > Reviewed-by: Christoph Hellwig <hch at lst.de> > > > > > > One comment on a related cleanup: > > > > > >

On Tue, Jul 23, 2019 at 02:05:06PM -0700, Ralph Campbell wrote: > The hmm_mirror_ops callback function sync_cpu_device_pagetables() passes > a struct hmm_update which is a simplified version of struct > mmu_notifier_range. This is unnecessary so replace hmm_update with > mmu_notifier_range directly. > > Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> > Cc:

From: Jason Gunthorpe <jgg at mellanox.com> The only two users of this are now converted to use mmu_interval_notifier, delete all the code and update hmm.rst. Reviewed-by: J?r?me Glisse <jglisse at redhat.com> Tested-by: Ralph Campbell <rcampbell at nvidia.com> Signed-off-by: Jason Gunthorpe <jgg at mellanox.com> --- Documentation/vm/hmm.rst | 105 ++++-----------

From: Jason Gunthorpe <jgg at mellanox.com> Remove the interval tree in the driver and rely on the tree maintained by the mmu_notifier for delivering mmu_notifier invalidation callbacks. For some reason amdgpu has a very complicated arrangement where it tries to prevent duplicate entries in the interval_tree, this is not necessary, each amdgpu_bo can be its own stand alone entry.

On 2019-10-28 4:10 p.m., Jason Gunthorpe wrote: > From: Jason Gunthorpe <jgg at mellanox.com> > > Remove the interval tree in the driver and rely on the tree maintained by > the mmu_notifier for delivering mmu_notifier invalidation callbacks. > > For some reason amdgpu has a very complicated arrangement where it tries > to prevent duplicate entries in the interval_tree,

From: Jason Gunthorpe <jgg at mellanox.com> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1, scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where they only use invalidate_range_start/end and immediately check the invalidating range against some driver data structure to tell if the driver is interested. Half of them use an interval_tree, the others

From: Jason Gunthorpe <jgg at mellanox.com> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1, scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where they only use invalidate_range_start/end and immediately check the invalidating range against some driver data structure to tell if the driver is interested. Half of them use an interval_tree, the others

Am 28.10.19 um 21:10 schrieb Jason Gunthorpe: > From: Jason Gunthorpe <jgg at mellanox.com> > > Remove the interval tree in the driver and rely on the tree maintained by > the mmu_notifier for delivering mmu_notifier invalidation callbacks. > > For some reason amdgpu has a very complicated arrangement where it tries > to prevent duplicate entries in the interval_tree,

Hi Dan, Jérôme and Jason, below is a series that cleans up the dev_pagemap interface so that it is more easily usable, which removes the need to wrap it in hmm and thus allowing to kill a lot of code Note: this series is on top of Linux 5.2-rc6 and has some minor conflicts with the hmm tree that are easy to resolve. Diffstat summary: 34 files changed, 379 insertions(+), 1016 deletions(-) Git

On Wed, Jul 24, 2019 at 12:28:58PM -0300, Jason Gunthorpe wrote: > Humm. Actually having looked this some more, I wonder if this is a > problem: What a mess. Question: do we even care for the non-blocking events? The only place where mmu_notifier_invalidate_range_start_nonblock is called is the oom killer, which means the process is about to die and the pagetable will get torn down ASAP.

On Wed 24-07-19 15:08:37, Jason Gunthorpe wrote: > On Wed, Jul 24, 2019 at 07:58:58PM +0200, Michal Hocko wrote: [...] > > Maybe new users have started relying on a new semantic in the meantime, > > back then, none of the notifier has even started any action in blocking > > mode on a EAGAIN bailout. Most of them simply did trylock early in the > > process and bailed out

On Wed, Jul 24, 2019 at 04:21:55PM -0300, Jason Gunthorpe wrote: > If we change the register to keep the hlist sorted by address then we > can do a targetted 'undo' of past starts terminated by address > less-than comparison of the first failing struct mmu_notifier. > > It relies on the fact that rcu is only used to remove items, the list > adds are all protected by mm

On Wed, Jul 24, 2019 at 08:59:10PM +0200, Michal Hocko wrote: > On Wed 24-07-19 20:56:17, Michal Hocko wrote: > > On Wed 24-07-19 15:08:37, Jason Gunthorpe wrote: > > > On Wed, Jul 24, 2019 at 07:58:58PM +0200, Michal Hocko wrote: > > [...] > > > > Maybe new users have started relying on a new semantic in the meantime, > > > > back then, none of the

On Wed 24-07-19 20:56:17, Michal Hocko wrote: > On Wed 24-07-19 15:08:37, Jason Gunthorpe wrote: > > On Wed, Jul 24, 2019 at 07:58:58PM +0200, Michal Hocko wrote: > [...] > > > Maybe new users have started relying on a new semantic in the meantime, > > > back then, none of the notifier has even started any action in blocking > > > mode on a EAGAIN bailout.

On Tue, Oct 29, 2019 at 07:22:37PM +0000, Yang, Philip wrote: > Hi Jason, > > I did quick test after merging amd-staging-drm-next with the > mmu_notifier branch, which includes this set changes. The test result > has different failures, app stuck intermittently, GUI no display etc. I > am understanding the changes and will try to figure out the cause. Thanks! I'm not

Hi Jason, I did quick test after merging amd-staging-drm-next with the mmu_notifier branch, which includes this set changes. The test result has different failures, app stuck intermittently, GUI no display etc. I am understanding the changes and will try to figure out the cause. Regards, Philip On 2019-10-28 4:10 p.m., Jason Gunthorpe wrote: > From: Jason Gunthorpe <jgg at