From: Alistair Popple <apopple@nvidia.com> To: David Hildenbrand <david@redhat.com> Cc: Alex Sierra <alex.sierra@amd.com>, jgg@nvidia.com, Felix.Kuehling@amd.com, linux-mm@kvack.org, rcampbell@nvidia.com, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, hch@lst.de, jglisse@redhat.com, willy@infradead.org, akpm@linux-foundation.org Subject: Re: [PATCH v8 06/15] mm: remove the vma check in migrate_vma_setup() Date: Thu, 14 Jul 2022 15:31:32 +1000 [thread overview] Message-ID: <87wncgckym.fsf@nvdebian.thelocal> (raw) In-Reply-To: <7a772ca0-0c82-2251-dd54-8ad466774e99@redhat.com> David Hildenbrand <david@redhat.com> writes: > On 07.07.22 21:03, Alex Sierra wrote: >> From: Alistair Popple <apopple@nvidia.com> >> >> migrate_vma_setup() checks that a valid vma is passed so that the page >> tables can be walked to find the pfns associated with a given address >> range. However in some cases the pfns are already known, such as when >> migrating device coherent pages during pin_user_pages() meaning a valid >> vma isn't required. > > As raised in my other reply, without a VMA ... it feels odd to use a > "migrate_vma" API. For an internal (mm/migrate_device.c) use case it is > ok I guess, but it certainly adds a bit of confusion. For example, > because migrate_vma_setup() will undo ref+lock not obtained by it. > > I guess the interesting point is that > > a) Besides migrate_vma_pages() and migrate_vma_setup(), the ->vma is unused. > > b) migrate_vma_setup() does collect+unmap+cleanup if unmap failed. > > c) With our source page in our hands, we cannot be processing a hole in > a VMA. > > > > Not sure if it's better. but I would > > a) Enforce in migrate_vma_setup() that there is a VMA. Code outside of > mm/migrate_device.c shouldn't be doing some hacks like this. > > b) Don't call migrate_vma_setup() from migrate_device_page(), but > directly migrate_vma_unmap() and add a comment. > > > That will leave a single change to this patch (migrate_vma_pages()). But > is that even required? Because .... > >> @@ -685,7 +685,7 @@ void migrate_vma_pages(struct migrate_vma *migrate) >> continue; >> } >> >> - if (!page) { >> + if (!page && migrate->vma) { > > How could we ever have !page in case of migrate_device_page()? Oh good point. This patch was originally part of a larger series I was working on at the time but you're right - for migrate_device_page() we should never hit this case. I will respin the next patch (number 7 in this series) to include this. > Instead, I think a VM_BUG_ON(migrate->vma); should hold and you can just > simplify. > >> if (!(migrate->src[i] & MIGRATE_PFN_MIGRATE)) >> continue; >> if (!notified) {
WARNING: multiple messages have this Message-ID (diff)
From: Alistair Popple <apopple@nvidia.com> To: David Hildenbrand <david@redhat.com> Cc: Alex Sierra <alex.sierra@amd.com>, rcampbell@nvidia.com, willy@infradead.org, Felix.Kuehling@amd.com, amd-gfx@lists.freedesktop.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, jglisse@redhat.com, dri-devel@lists.freedesktop.org, jgg@nvidia.com, akpm@linux-foundation.org, linux-ext4@vger.kernel.org, hch@lst.de Subject: Re: [PATCH v8 06/15] mm: remove the vma check in migrate_vma_setup() Date: Thu, 14 Jul 2022 15:31:32 +1000 [thread overview] Message-ID: <87wncgckym.fsf@nvdebian.thelocal> (raw) In-Reply-To: <7a772ca0-0c82-2251-dd54-8ad466774e99@redhat.com> David Hildenbrand <david@redhat.com> writes: > On 07.07.22 21:03, Alex Sierra wrote: >> From: Alistair Popple <apopple@nvidia.com> >> >> migrate_vma_setup() checks that a valid vma is passed so that the page >> tables can be walked to find the pfns associated with a given address >> range. However in some cases the pfns are already known, such as when >> migrating device coherent pages during pin_user_pages() meaning a valid >> vma isn't required. > > As raised in my other reply, without a VMA ... it feels odd to use a > "migrate_vma" API. For an internal (mm/migrate_device.c) use case it is > ok I guess, but it certainly adds a bit of confusion. For example, > because migrate_vma_setup() will undo ref+lock not obtained by it. > > I guess the interesting point is that > > a) Besides migrate_vma_pages() and migrate_vma_setup(), the ->vma is unused. > > b) migrate_vma_setup() does collect+unmap+cleanup if unmap failed. > > c) With our source page in our hands, we cannot be processing a hole in > a VMA. > > > > Not sure if it's better. but I would > > a) Enforce in migrate_vma_setup() that there is a VMA. Code outside of > mm/migrate_device.c shouldn't be doing some hacks like this. > > b) Don't call migrate_vma_setup() from migrate_device_page(), but > directly migrate_vma_unmap() and add a comment. > > > That will leave a single change to this patch (migrate_vma_pages()). But > is that even required? Because .... > >> @@ -685,7 +685,7 @@ void migrate_vma_pages(struct migrate_vma *migrate) >> continue; >> } >> >> - if (!page) { >> + if (!page && migrate->vma) { > > How could we ever have !page in case of migrate_device_page()? Oh good point. This patch was originally part of a larger series I was working on at the time but you're right - for migrate_device_page() we should never hit this case. I will respin the next patch (number 7 in this series) to include this. > Instead, I think a VM_BUG_ON(migrate->vma); should hold and you can just > simplify. > >> if (!(migrate->src[i] & MIGRATE_PFN_MIGRATE)) >> continue; >> if (!notified) {
next prev parent reply other threads:[~2022-07-14 5:38 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-07-07 19:03 [PATCH v8 00/15] Add MEMORY_DEVICE_COHERENT for coherent device memory mapping Alex Sierra 2022-07-07 19:03 ` Alex Sierra 2022-07-07 19:03 ` [PATCH v8 01/15] mm: rename is_pinnable_pages to is_longterm_pinnable_pages Alex Sierra 2022-07-07 19:03 ` Alex Sierra 2022-07-08 11:26 ` David Hildenbrand 2022-07-08 11:26 ` David Hildenbrand 2022-07-07 19:03 ` [PATCH v8 02/15] mm: move page zone helpers into new header-specific file Alex Sierra 2022-07-07 19:03 ` Alex Sierra 2022-07-08 11:28 ` David Hildenbrand 2022-07-08 11:28 ` David Hildenbrand 2022-07-08 21:25 ` Felix Kuehling 2022-07-08 21:25 ` Felix Kuehling 2022-07-11 13:56 ` David Hildenbrand 2022-07-11 13:56 ` David Hildenbrand 2022-07-14 16:15 ` [PATCH] mm: move page zone helpers from mm.h to mmzone.h Alex Sierra 2022-07-14 16:15 ` Alex Sierra 2022-07-07 19:03 ` [PATCH v8 03/15] mm: add zone device coherent type memory support Alex Sierra 2022-07-07 19:03 ` Alex Sierra 2022-07-07 19:03 ` [PATCH v8 04/15] mm: handling Non-LRU pages returned by vm_normal_pages Alex Sierra 2022-07-07 19:03 ` Alex Sierra 2022-07-07 19:03 ` [PATCH v8 05/15] mm: add device coherent vma selection for memory migration Alex Sierra 2022-07-07 19:03 ` Alex Sierra 2022-07-07 19:03 ` [PATCH v8 06/15] mm: remove the vma check in migrate_vma_setup() Alex Sierra 2022-07-07 19:03 ` Alex Sierra 2022-07-11 13:52 ` David Hildenbrand 2022-07-11 13:52 ` David Hildenbrand 2022-07-14 5:31 ` Alistair Popple [this message] 2022-07-14 5:31 ` Alistair Popple 2022-07-07 19:03 ` [PATCH v8 07/15] mm/gup: migrate device coherent pages when pinning instead of failing Alex Sierra 2022-07-07 19:03 ` Alex Sierra 2022-07-11 13:35 ` David Hildenbrand 2022-07-11 13:35 ` David Hildenbrand 2022-07-11 14:00 ` Matthew Wilcox 2022-07-11 14:00 ` Matthew Wilcox 2022-07-11 14:00 ` David Hildenbrand 2022-07-11 14:00 ` David Hildenbrand 2022-07-15 2:11 ` [PATCH] " Alistair Popple 2022-07-15 2:11 ` Alistair Popple 2022-07-15 14:12 ` Sierra Guiza, Alejandro (Alex) 2022-07-15 14:12 ` Sierra Guiza, Alejandro (Alex) 2022-07-14 5:39 ` [PATCH v8 07/15] " Alistair Popple 2022-07-14 5:39 ` Alistair Popple 2022-07-07 19:03 ` [PATCH v8 08/15] drm/amdkfd: add SPM support for SVM Alex Sierra 2022-07-07 19:03 ` Alex Sierra 2022-07-07 19:03 ` [PATCH v8 09/15] lib: test_hmm add ioctl to get zone device type Alex Sierra 2022-07-07 19:03 ` Alex Sierra 2022-07-07 19:03 ` [PATCH v8 10/15] lib: test_hmm add module param for " Alex Sierra 2022-07-07 19:03 ` Alex Sierra 2022-07-07 19:03 ` [PATCH v8 11/15] lib: add support for device coherent type in test_hmm Alex Sierra 2022-07-07 19:03 ` Alex Sierra 2022-07-07 19:03 ` [PATCH v8 12/15] tools: update hmm-test to support device coherent type Alex Sierra 2022-07-07 19:03 ` Alex Sierra 2022-07-07 19:03 ` [PATCH v8 13/15] tools: update test_hmm script to support SP config Alex Sierra 2022-07-07 19:03 ` Alex Sierra 2022-07-07 19:03 ` [PATCH v8 14/15] tools: add hmm gup tests for device coherent type Alex Sierra 2022-07-07 19:03 ` Alex Sierra 2022-07-07 19:03 ` [PATCH v8 15/15] tools: add selftests to hmm for COW in device memory Alex Sierra 2022-07-07 19:03 ` Alex Sierra
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87wncgckym.fsf@nvdebian.thelocal \ --to=apopple@nvidia.com \ --cc=Felix.Kuehling@amd.com \ --cc=akpm@linux-foundation.org \ --cc=alex.sierra@amd.com \ --cc=amd-gfx@lists.freedesktop.org \ --cc=david@redhat.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=hch@lst.de \ --cc=jgg@nvidia.com \ --cc=jglisse@redhat.com \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-xfs@vger.kernel.org \ --cc=rcampbell@nvidia.com \ --cc=willy@infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.