search for: migrate_vma_select_device_priv

...with mmap_lock write lock held just for @@ -577,7 +578,8 @@ kvmppc_svm_page_out(struct vm_area_struct *vma, unsigned long start, mig.end = end; mig.src = &src_pfn; mig.dst = &dst_pfn; - mig.src_owner = &kvmppc_uvmem_pgmap; + mig.pgmap_owner = &kvmppc_uvmem_pgmap; + mig.flags = MIGRATE_VMA_SELECT_DEVICE_PRIVATE; mutex_lock(&kvm->arch.uvmem_lock); /* The requested page is already paged-out, nothing to do */ diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c index e5c230d9ae24..78b9e3c2a5b3 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c +++ b/dr...

...with mmap_lock write lock held just for @@ -577,7 +578,8 @@ kvmppc_svm_page_out(struct vm_area_struct *vma, unsigned long start, mig.end = end; mig.src = &src_pfn; mig.dst = &dst_pfn; - mig.src_owner = &kvmppc_uvmem_pgmap; + mig.pgmap_owner = &kvmppc_uvmem_pgmap; + mig.flags = MIGRATE_VMA_SELECT_DEVICE_PRIVATE; mutex_lock(&kvm->arch.uvmem_lock); /* The requested page is already paged-out, nothing to do */ diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c index e5c230d9ae24..78b9e3c2a5b3 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c +++ b/dr...

The goal for this series is to avoid device private memory TLB invalidations when migrating a range of addresses from system memory to device private memory and some of those pages have already been migrated. The approach taken is to introduce a new mmu notifier invalidation event type and use that in the device driver to skip invalidation callbacks from migrate_vma_setup(). The device driver is

...ions of > d->d, d->s, s->d, and s->s being valid. > > I didn't really think a direction was needed, this was something that > Christoph Hellwig seemed to think made the API safer. If it is a filter then just using those names would make sense MIGRATE_VMA_SELECT_SYSTEM MIGRATE_VMA_SELECT_DEVICE_PRIVATE SYSTEM feels like the wrong name too, doesn't linux have a formal name for RAM struct pages? In your future coherent design how would the migrate select 'device' pages that are fully coherent? Are they still zone something pages that are OK for CPU usage? Jason

The goal for this series is to avoid device private memory TLB invalidations when migrating a range of addresses from system memory to device private memory and some of those pages have already been migrated. The approach taken is to introduce a new mmu notifier invalidation event type and use that in the device driver to skip invalidation callbacks from migrate_vma_setup(). The device driver is

...;d, and s->s being valid. >> >> I didn't really think a direction was needed, this was something that >> Christoph Hellwig seemed to think made the API safer. > > If it is a filter then just using those names would make sense > > MIGRATE_VMA_SELECT_SYSTEM > MIGRATE_VMA_SELECT_DEVICE_PRIVATE > > SYSTEM feels like the wrong name too, doesn't linux have a formal name > for RAM struct pages? Highmem? Movable? Zone normal? There are quite a few :-) At the moment, only anonymous pages are being migrated but I expect file backed pages to be supported at some point (but not...

...e.h index aafec0ca7b41..4cc7097d0271 100644 --- a/include/linux/migrate.h +++ b/include/linux/migrate.h @@ -206,6 +206,9 @@ struct migrate_vma { * Set to the owner value also stored in page->pgmap->owner for * migrating out of device private memory. The flags also need to * be set to MIGRATE_VMA_SELECT_DEVICE_PRIVATE. + * The caller should always set this field when using mmu notifier + * callbacks to avoid device MMU invalidations for device private + * pages that are not being migrated. */ void *pgmap_owner; unsigned long flags; diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_not...

...e.h index aafec0ca7b41..4cc7097d0271 100644 --- a/include/linux/migrate.h +++ b/include/linux/migrate.h @@ -206,6 +206,9 @@ struct migrate_vma { * Set to the owner value also stored in page->pgmap->owner for * migrating out of device private memory. The flags also need to * be set to MIGRATE_VMA_SELECT_DEVICE_PRIVATE. + * The caller should always set this field when using mmu notifier + * callbacks to avoid device MMU invalidations for device private + * pages that are not being migrated. */ void *pgmap_owner; unsigned long flags; diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_not...

On Mon, Jul 20, 2020 at 12:54:53PM -0700, Ralph Campbell wrote: > > > diff --git a/include/linux/migrate.h b/include/linux/migrate.h > > > index 3e546cbf03dd..620f2235d7d4 100644 > > > +++ b/include/linux/migrate.h > > > @@ -180,6 +180,11 @@ static inline unsigned long migrate_pfn(unsigned long pfn) > > > return (pfn << MIGRATE_PFN_SHIFT) |

This series adds support for transparent huge page migration to migrate_vma_*() and adds nouveau SVM and HMM selftests as consumers. Earlier versions were posted previously [1] and [2]. The patches apply cleanly to the linux-mm 5.10.0-rc2 tree. There are a lot of other THP patches being posted. I don't think there are any semantic conflicts but there may be some merge conflicts depending on

This series adds support for transparent huge page migration to migrate_vma_*() and adds nouveau SVM and HMM selftests as consumers. An earlier version was posted previously [1]. This version now supports splitting a THP midway in the migration process which led to a number of changes. The patches apply cleanly to the current linux-mm tree. Since there are a couple of patches in linux-mm from Dan

...#define MIGRATE_PFN_COMPOUND (1UL << 4) #define MIGRATE_PFN_SHIFT 6 static inline struct page *migrate_pfn_to_page(unsigned long mpfn) @@ -161,6 +162,7 @@ static inline unsigned long migrate_pfn(unsigned long pfn) enum migrate_vma_direction { MIGRATE_VMA_SELECT_SYSTEM = 1 << 0, MIGRATE_VMA_SELECT_DEVICE_PRIVATE = 1 << 1, + MIGRATE_VMA_SELECT_COMPOUND = 1 << 2, }; struct migrate_vma { diff --git a/mm/huge_memory.c b/mm/huge_memory.c index b4141f12ff31..a073e66d0ee2 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1682,23 +1682,35 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct...

Hi folks, Currently, when the device is removed (or the driver is unbound) the nouveau_drm structure de-allocated. However, it's still accessible from and used by some DRM layer callbacks. For example, file handles can be closed after the device has been removed (physically or otherwise). This series converts the Nouveau device structure to be allocated and de-allocated with the