search for: mmu_notifier_rang

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: "Jérôme Glisse" <jglisse at redhat.com> Cc: Jason Gunthorpe <jgg at mellanox.com> Cc: Christoph Hellwig <hch at lst.de> Cc: Be...

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: "Jérôme Glisse" <jglisse at redhat.com> > Cc: Jason Gunthorpe <jgg at mellanox.com> > Cc: Christoph Hellwi...

...> CPU page table unmapping handled by migrate_vma_setup(). To support > this, the caller of migrate_vma_setup() should always set struct > migrate_vma::src_owner to a non NULL value that matches the device > private page->pgmap->owner. This value is then passed to the struct > mmu_notifier_range with a new event type which the driver's invalidation > function can use to avoid device MMU invalidations. > > Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> > include/linux/mmu_notifier.h | 7 +++++++ > mm/migrate.c | 8 +++++++- > 2 files c...

...mm->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 (WARN_ON(update.blockable || rc != -EAGAIN)) > + if (WARN_ON(mmu_notifier_range_blockable(nrange) || > + rc != -EAGAIN)) > continue; > ret = -EAGAIN; > break; This magic handling of error seems odd. I think we should merge rc and ret into one variable and just break out if any error happens instead or claiming in the comments -EAGAIN is the on...

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.

...; > > - rc = mirror->ops->sync_cpu_device_pagetables(mirror, &update); > > > + rc = mirror->ops->sync_cpu_device_pagetables(mirror, nrange); > > > if (rc) { > > > - if (WARN_ON(update.blockable || rc != -EAGAIN)) > > > + if (WARN_ON(mmu_notifier_range_blockable(nrange) || > > > + rc != -EAGAIN)) > > > continue; > > > ret = -EAGAIN; > > > break; > > > > This magic handling of error seems odd. I think we should merge rc and > > ret into one variable and just break out if a...

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

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 invalidate_range_start() or do some special thing with it. It turns out that building a...

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 invalidate_range_start() or do some special thing with it. It turns out that building a...

...event to mmu_range_notifier_ops.invalidate() i failed to catch > > > that in v1 sorry. > > > > I think what you mean is already done? > > > > struct mmu_range_notifier_ops { > > bool (*invalidate)(struct mmu_range_notifier *mrn, > > const struct mmu_notifier_range *range, > > unsigned long cur_seq); > > Yes it is sorry, i got confuse with mmu_range_notifier and mmu_notifier_range :) > It is almost a palyndrome structure ;) Lets change the name then, this is clearly not working. I'll reflow everything tomorrow Jason

...e device driver and leave CPU page table unmapping handled by migrate_vma_setup(). To support this, the caller of migrate_vma_setup() should always set struct migrate_vma::src_owner to a non NULL value that matches the device private page->pgmap->owner. This value is then passed to the struct mmu_notifier_range with a new event type which the driver's invalidation function can use to avoid device MMU invalidations. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- include/linux/mmu_notifier.h | 7 +++++++ mm/migrate.c | 8 +++++++- 2 files changed, 14 insertions(+),...

...e device driver and leave CPU page table unmapping handled by migrate_vma_setup(). To support this, the caller of migrate_vma_setup() should always set struct migrate_vma::src_owner to a non NULL value that matches the device private page->pgmap->owner. This value is then passed to the struct mmu_notifier_range with a new event type which the driver's invalidation function can use to avoid device MMU invalidations. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- include/linux/mmu_notifier.h | 7 +++++++ mm/migrate.c | 8 +++++++- 2 files changed, 14 insertions(+),...

...stay with "mmu_range_notifier" as a core name for this > > whole thing. > > > > 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 called with > this type, it is still part of the mmu_notifier_range. > > The comment already says it only applies to the mmu_range_notifier > scheme.. In fact the...

...device driver and leave CPU page table unmapping handled by migrate_vma_setup(). To support this, the caller of migrate_vma_setup() should always set struct migrate_vma::pgmap_owner to a non NULL value that matches the device private page->pgmap->owner. This value is then passed to the struct mmu_notifier_range with a new event type which the driver's invalidation function can use to avoid device MMU invalidations. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- include/linux/migrate.h | 3 +++ include/linux/mmu_notifier.h | 7 +++++++ mm/migrate.c | 8 +++++++...

...device driver and leave CPU page table unmapping handled by migrate_vma_setup(). To support this, the caller of migrate_vma_setup() should always set struct migrate_vma::pgmap_owner to a non NULL value that matches the device private page->pgmap->owner. This value is then passed to the struct mmu_notifier_range with a new event type which the driver's invalidation function can use to avoid device MMU invalidations. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- include/linux/migrate.h | 3 +++ include/linux/mmu_notifier.h | 7 +++++++ mm/migrate.c | 8 +++++++...

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.

...> CPU page table unmapping handled by migrate_vma_setup(). To support > this, the caller of migrate_vma_setup() should always set struct > migrate_vma::src_owner to a non NULL value that matches the device > private page->pgmap->owner. This value is then passed to the struct > mmu_notifier_range with a new event type which the driver's invalidation > function can use to avoid device MMU invalidations. > > Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> > include/linux/mmu_notifier.h | 7 +++++++ > mm/migrate.c | 8 +++++++- > 2 files c...

...mirror->ops->sync_cpu_device_pagetables(mirror, &update); > > > > + rc = mirror->ops->sync_cpu_device_pagetables(mirror, nrange); > > > > if (rc) { > > > > - if (WARN_ON(update.blockable || rc != -EAGAIN)) > > > > + if (WARN_ON(mmu_notifier_range_blockable(nrange) || > > > > + rc != -EAGAIN)) > > > > continue; > > > > ret = -EAGAIN; > > > > break; > > > > > > This magic handling of error seems odd. I think we should merge rc and > > > ret into o...