similar to: [PATCH v2 00/15] Consolidate the mmu notifier interval_tree and locking

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

On 10/28/19 1:10 PM, Jason Gunthorpe wrote: ... > include/linux/mmu_notifier.h | 98 +++++++ > mm/Kconfig | 1 + > mm/mmu_notifier.c | 533 +++++++++++++++++++++++++++++++++-- > 3 files changed, 607 insertions(+), 25 deletions(-) > > diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h > index 12bd603d318ce7..51b92ba013ddce

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

On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote: > > > > Extra credit: IMHO, this clearly deserves to all be in a new mmu_range_notifier.h > > header file, but I know that's extra work. Maybe later as a follow-up patch, > > if anyone has the time. > > The range notifier should get the event too, it would be a waste, i think it is > an oversight

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 Wed, Nov 06, 2019 at 04:23:21PM -0800, John Hubbard wrote: > Nice design, I love the seq foundation! So far, I'm not able to spot anything > actually wrong with the implementation, sorry about that. Alas :( I feel there must be a bug in here still, but onwards! One of the main sad points was it didn't make sense to use the existing seqlock/seqcount primitives as they have

I haven't had enough time to fully understand the deferred logic in this change. I spotted one problem, see comments inline. On 2019-10-28 4:10 p.m., Jason Gunthorpe wrote: > From: Jason Gunthorpe <jgg at mellanox.com> > > Of the 13 users of mmu_notifiers, 8 of them use only > invalidate_range_start/end() and immediately intersect the > mmu_notifier_range with some kind

This series adds new functions to the mmu interval notifier API to allow device drivers with MMUs to dynamically mirror a process' page tables based on device faults and invalidation callbacks. The Nouveau driver is updated to use the extended API and a set of stand alone self tests is added to help validate and maintain correctness. The patches are based on linux-5.5.0-rc6 and are for

From: Jason Gunthorpe <jgg at mellanox.com> Of the 13 users of mmu_notifiers, 8 of them use only invalidate_range_start/end() and immediately intersect the mmu_notifier_range with some kind of internal list of VAs. 4 use an interval tree (i915_gem, radeon_mn, umem_odp, hfi1). 4 use a linked list of some kind (scif_dma, vhost, gntdev, hmm) And the remaining 5 either don't use

On 11/13/19 8:46 AM, Jason Gunthorpe wrote: > On Wed, Nov 13, 2019 at 05:59:52AM -0800, Christoph Hellwig wrote: >>> +int mmu_interval_notifier_insert(struct mmu_interval_notifier *mni, >>> + struct mm_struct *mm, unsigned long start, >>> + unsigned long length, >>> + const struct mmu_interval_notifier_ops *ops); >>> +int

On Mon, Jan 13, 2020 at 02:47:01PM -0800, Ralph Campbell wrote: > diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c > index 47ad9cc89aab..4efecc0f13cb 100644 > +++ b/mm/mmu_notifier.c > @@ -1171,6 +1171,39 @@ void mmu_interval_notifier_update(struct mmu_interval_notifier *mni, > } > EXPORT_SYMBOL_GPL(mmu_interval_notifier_update); > > +struct mmu_interval_notifier

On Fri, Nov 01, 2019 at 02:44:51PM +0000, Yang, Philip wrote: > > > On 2019-10-29 3:25 p.m., Jason Gunthorpe wrote: > > 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 >

On Thu, Nov 07, 2019 at 04:04:08PM -0500, Jerome Glisse wrote: > On Thu, Nov 07, 2019 at 08:11:06PM +0000, Jason Gunthorpe wrote: > > On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote: > > > > > > > > > > Extra credit: IMHO, this clearly deserves to all be in a new mmu_range_notifier.h > > > > header file, but I know that's extra

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, Nov 06, 2019 at 04:23:21PM -0800, John Hubbard wrote: > On 10/28/19 1:10 PM, Jason Gunthorpe wrote: [...] > > /** > > * enum mmu_notifier_event - reason for the mmu notifier callback > > @@ -32,6 +34,9 @@ struct mmu_notifier_range; > > * access flags). User should soft dirty the page in the end callback to make > > * sure that anyone relying on

On 11/7/19 12:06 PM, Jason Gunthorpe wrote: ... >> >> Also, it is best moved down to be next to the new MNR structs, so that all the >> MNR stuff is in one group. > > I agree with Jerome, this enum is part of the 'struct > mmu_notifier_range' (ie the description of the invalidation) and it > doesn't really matter that only these new notifiers can be

From: Jason Gunthorpe <jgg at mellanox.com> Convert the collision-retry lock around hmm_range_fault to use the one now provided by the mmu_range notifier. Although this driver does not seem to use the collision retry lock that hmm provides correctly, it can still be converted over to use the mmu_range_notifier api instead of hmm_mirror without too much trouble. This also deletes another

On 10/28/19 1:10 PM, Jason Gunthorpe wrote: > 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

On Thu, Nov 07, 2019 at 08:11:06PM +0000, Jason Gunthorpe wrote: > On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote: > > > > > > > Extra credit: IMHO, this clearly deserves to all be in a new mmu_range_notifier.h > > > header file, but I know that's extra work. Maybe later as a follow-up patch, > > > if anyone has the time. > >

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