search for: migrate_vma_

...computes the GPU's physical > address of local memory leading to data corruption. > Fix this by checking the source struct page and computing the correct > physical address. I'm really worried about all this delicate code to fix the mixed ranges. Can't we make it clear at the migrate_vma_* level if we want to migrate from 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.

...ss of local memory leading to data corruption. >>> Fix this by checking the source struct page and computing the correct >>> physical address. >> >> I'm really worried about all this delicate code to fix the mixed >> ranges.? Can't we make it clear at the migrate_vma_* level if we want >> to migrate from 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 c...

...ical >> address of local memory leading to data corruption. >> Fix this by checking the source struct page and computing the correct >> physical address. > > I'm really worried about all this delicate code to fix the mixed > ranges. Can't we make it clear at the migrate_vma_* level if we want > to migrate from 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 d...

...a corruption. > > > > Fix this by checking the source struct page and computing the correct > > > > physical address. > > > > > > I'm really worried about all this delicate code to fix the mixed > > > ranges.? Can't we make it clear at the migrate_vma_* level if we want > > > to migrate from 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. &...

On Fri, Aug 16, 2019 at 06:44:48AM +0200, Christoph Hellwig wrote: > On Fri, Aug 16, 2019 at 12:43:07AM +0000, Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 04:51:33PM -0400, Jerome Glisse wrote: > > > > > struct page. In this case any way we can update the > > > nouveau_dmem_page() to check that page page->pgmap == the > > > expected pgmap. >

On 7/28/20 12:19 PM, Jason Gunthorpe wrote: > On Thu, Jul 23, 2020 at 03:30:04PM -0700, Ralph Campbell wrote: >> When migrating the special zero page, migrate_vma_pages() calls >> mmu_notifier_invalidate_range_start() before replacing the zero page >> PFN in the CPU page tables. This is unnecessary since the range was >> invalidated in migrate_vma_setup() and the page table entry is checked >> to be sure it hasn't changed between m...

...s also needs some fstests exposure. > I have a modified THP migration patch series that applies on top of > this one and is cleaner since I don't have to add code to handle the > +1 reference count. The link below is for the earlier v2: > ("mm/hmm/nouveau: add THP migration to migrate_vma_*") > https://lore.kernel.org/linux-mm/20200902165830.5367-1-rcampbell at nvidia.com > > > arch/powerpc/kvm/book3s_hv_uvmem.c | 1 - > drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 - > include/linux/memremap.h | 6 +-- > include/linux/mm.h...

...t be OK. I could use help testing these configurations. I have a modified THP migration patch series that applies on top of this one and is cleaner since I don't have to add code to handle the +1 reference count. The link below is for the earlier v2: ("mm/hmm/nouveau: add THP migration to migrate_vma_*") https://lore.kernel.org/linux-mm/20200902165830.5367-1-rcampbell at nvidia.com arch/powerpc/kvm/book3s_hv_uvmem.c | 1 - drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 - include/linux/memremap.h | 6 +-- include/linux/mm.h | 39 --------------- lib/t...

...e. Got it. Thanks! >> I have a modified THP migration patch series that applies on top of >> this one and is cleaner since I don't have to add code to handle the >> +1 reference count. The link below is for the earlier v2: >> ("mm/hmm/nouveau: add THP migration to migrate_vma_*") >> https://lore.kernel.org/linux-mm/20200902165830.5367-1-rcampbell at nvidia.com >> >> >> arch/powerpc/kvm/book3s_hv_uvmem.c | 1 - >> drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 - >> include/linux/memremap.h | 6 +-- >> i...

On Thu, Jul 23, 2020 at 03:30:04PM -0700, Ralph Campbell wrote: > When migrating the special zero page, migrate_vma_pages() calls > mmu_notifier_invalidate_range_start() before replacing the zero page > PFN in the CPU page tables. This is unnecessary since the range was > invalidated in migrate_vma_setup() and the page table entry is checked > to be sure it hasn't changed between migrate_vma_setup...

...gt; Reviewed-by: Yang Shi <shy828301 at gmail.com> Reviewed-by: Zi Yan <ziy at nvidia.com> --- No changes in v3 to this patch, just added reviewed-by and fixes to the change log and sending this as a separate patch from the rest of the series ("mm/hmm/nouveau: add THP migration to migrate_vma_*"). I'll hold off resending the series without this patch unless there are changes needed. mm/huge_memory.c | 42 +++++++++++++++++++++++------------------- 1 file changed, 23 insertions(+), 19 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 2a468a4acb0a..606d712d950...

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...

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 patc...

These are based on 5.8.0-rc2 and intended for Ben Skeggs' nouveau tree. I believe the changes can be queued for 5.8-rcX after being reviewed. These were part of a larger series but I'm resending them separately as suggested by Jason Gunthorpe. https://lore.kernel.org/linux-mm/20200619215649.32297-1-rcampbell at nvidia.com/ Note that in order to exercise/test patch 2 here, you will need a