All of lore.kernel.org
 help / color / mirror / Atom feed
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) {

  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: link
Be 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.