search for: src_owner

The caller of migrate_vma_setup() does not know what type of page is stored in the CPU's page tables. Pages within the specified range are free to be swapped out, migrated, or freed until after migrate_vma_setup() returns. The caller needs to set struct migrate_vma.src_owner in case a page is a ZONE device private page that the device owns and might want to migrate. However, the current code skips normal anonymous pages if src_owner is set, thus preventing those pages from being migrated. Remove the src_owner check for normal pages since src_owner only applies to devic...

The src_owner field in struct migrate_vma is being used for two purposes, it implies the direction of the migration and it identifies device private pages owned by the caller. Split this into separate parameters so the src_owner field can be used just to identify device private pages owned by the caller of migra...

The src_owner field in struct migrate_vma is being used for two purposes, it implies the direction of the migration and it identifies device private pages owned by the caller. Split this into separate parameters so the src_owner field can be used just to identify device private pages owned by the caller of migra...

The src_owner field in struct migrate_vma is being used for two purposes, it acts as a selection filter for which types of pages are to be migrated and it identifies device private pages owned by the caller. Split this into separate parameters so the src_owner field can be used just to identify device private pa...

The src_owner field in struct migrate_vma is being used for two purposes, it acts as a selection filter for which types of pages are to be migrated and it identifies device private pages owned by the caller. Split this into separate parameters so the src_owner field can be used just to identify device private pa...

...er can simply invalidate its MMU in the mmu notifier callback and not handle MMU invalidations in the migration sequence. This series is based on Jason Gunthorpe's HMM tree (linux-5.8.0-rc4). Also, this replaces the need for the following two patches I sent: ("mm: fix migrate_vma_setup() src_owner and normal pages") https://lore.kernel.org/linux-mm/20200622222008.9971-1-rcampbell at nvidia.com ("nouveau: fix mixed normal and device private page migration") https://lore.kernel.org/lkml/20200622233854.10889-3-rcampbell at nvidia.com Changes in v2: Rebase to Jason Gunthorpe'...

...x-mm/20200701225352.9649-1-rcampbell at nvidia.com There are no logical dependencies, but there would be merge conflicts which could be resolved if this were to be applied before the other series. Also, this replaces the need for the following two patches I sent: ("mm: fix migrate_vma_setup() src_owner and normal pages") https://lore.kernel.org/linux-mm/20200622222008.9971-1-rcampbell at nvidia.com ("nouveau: fix mixed normal and device private page migration") https://lore.kernel.org/lkml/20200622233854.10889-3-rcampbell at nvidia.com Ralph Campbell (5): nouveau: fix storing in...

...or two device private memory, and then skip all the work >> for regions of memory that already are in the right place?? This might be >> a little more work initially, but I think it leads to a much better >> API. >> > > The current code does encode the direction with src_owner != NULL meaning > device private to system memory and src_owner == NULL meaning system > memory to device private memory. This patch would obviously defeat that > so perhaps a flag could be added to the struct migrate_vma to indicate the > direction but I'm unclear how that makes th...

...r 18, 2020 at 09:28:49PM -0300, Jason Gunthorpe wrote: > > Changes since v1: > > - split out the pgmap->owner addition into a separate patch > > - check pgmap->owner is set for device private mappings > > - rename the dev_private_owner field in struct migrate_vma to src_owner > > - refuse to migrate private pages if src_owner is not set > > - keep the non-fault device private handling in hmm_range_fault > > I'm happy enough to take this, did you have plans for a v3? I think the only open question is if merging 3 and 4 might make sense. It's...

Add a new src_owner field to struct migrate_vma. If the field is set, only device private pages with page->pgmap->owner equal to that field are migrated. If the field is not set only "normal" pages are migrated. Signed-off-by: Christoph Hellwig <hch at lst.de> Fixes: df6ad69838fc ("mm/dev...

...ce mappings that are not being migrated, shift the responsibility > for clearing device private mappings to 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::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 Campb...

On Mon, Jul 13, 2020 at 10:21:46AM -0700, Ralph Campbell wrote: > The src_owner field in struct migrate_vma is being used for two purposes, > it implies the direction of the migration and it identifies device private > pages owned by the caller. Split this into separate parameters so the > src_owner field can be used just to identify device private pages owned > by...

...er can simply invalidate its MMU in the mmu notifier callback and not handle MMU invalidations in the migration sequence. This series is based on Jason Gunthorpe's HMM tree (linux-5.8.0-rc4). Also, this replaces the need for the following two patches I sent: ("mm: fix migrate_vma_setup() src_owner and normal pages") https://lore.kernel.org/linux-mm/20200622222008.9971-1-rcampbell at nvidia.com ("nouveau: fix mixed normal and device private page migration") https://lore.kernel.org/lkml/20200622233854.10889-3-rcampbell at nvidia.com Bharata Rao, let me know if I can add your re...

On Mon, Jun 22, 2020 at 04:38:53PM -0700, Ralph Campbell wrote: > The OpenCL function clEnqueueSVMMigrateMem(), without any flags, will > migrate memory in the given address range to device private memory. The > source pages might already have been migrated to device private memory. > In that case, the source struct page is not checked to see if it is > a device private page and

...ng and fully tested code, and then should pass the expected owner in the hmm_range structure. Changes since v1: - split out the pgmap->owner addition into a separate patch - check pgmap->owner is set for device private mappings - rename the dev_private_owner field in struct migrate_vma to src_owner - refuse to migrate private pages if src_owner is not set - keep the non-fault device private handling in hmm_range_fault

On 7/20/20 11:36 AM, Jason Gunthorpe wrote: > On Mon, Jul 13, 2020 at 10:21:46AM -0700, Ralph Campbell wrote: >> The src_owner field in struct migrate_vma is being used for two purposes, >> it implies the direction of the migration and it identifies device private >> pages owned by the caller. Split this into separate parameters so the >> src_owner field can be used just to identify device private pages o...

...er can simply invalidate its MMU in the mmu notifier callback and not handle MMU invalidations in the migration sequence. This series is based on Jason Gunthorpe's HMM tree (linux-5.8.0-rc4). Also, this replaces the need for the following two patches I sent: ("mm: fix migrate_vma_setup() src_owner and normal pages") https://lore.kernel.org/linux-mm/20200622222008.9971-1-rcampbell at nvidia.com ("nouveau: fix mixed normal and device private page migration") https://lore.kernel.org/lkml/20200622233854.10889-3-rcampbell at nvidia.com Changes in v4: Added reviewed-by from Bharata...

...P_V0_VRAM | > ((paddr >> PAGE_SHIFT) << NVIF_VMM_PFNMAP_V0_ADDR_SHIFT); > if (src & MIGRATE_PFN_WRITE) > @@ -615,6 +622,7 @@ nouveau_dmem_migrate_vma(struct nouveau_drm *drm, > struct migrate_vma args = { > .vma = vma, > .start = start, > + .src_owner = drm->dev, Hi Ralph, This .src_owner setting does look like a required fix, but it seems like a completely separate fix from what is listed in this patch's commit description, right? (It feels like a casualty of rearranging the patches.) thanks, -- John Hubbard NVIDIA

...to not disrupt device mappings that are not being migrated, shift the responsibility for clearing device private mappings to 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::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 nvid...

...to not disrupt device mappings that are not being migrated, shift the responsibility for clearing device private mappings to 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::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 nvid...