All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alistair Popple <apopple@nvidia.com>
To: <akpm@linux-foundation.org>, <linux-mm@kvack.org>,
	<rcampbell@nvidia.com>,  <linux-ext4@vger.kernel.org>,
	<linux-xfs@vger.kernel.org>, Alex Sierra <alex.sierra@amd.com>,
	Felix Kuehling <felix.kuehling@amd.com>
Cc: amd-gfx@lists.freedesktop.org, willy@infradead.org,
	jglisse@redhat.com, dri-devel@lists.freedesktop.org,
	jgg@nvidia.com, hch@lst.de
Subject: Re: [PATCH v1 1/9] mm: add zone device coherent type memory support
Date: Tue, 23 Nov 2021 18:10:05 +1100	[thread overview]
Message-ID: <3642425.Elj8dHrGez@nvdebian> (raw)
In-Reply-To: <f45fb007-ccc4-4d09-b609-09faa81d3b81@amd.com>

On Tuesday, 23 November 2021 4:16:55 AM AEDT Felix Kuehling wrote:

[...]

> > Right, so long as my fix goes in I don't think there is anything wrong with
> > pinning device public pages. Agree that we should avoid FOLL_LONGTERM pins for
> > device memory though. I think the way to do that is update is_pinnable_page()
> > so we treat device pages the same as other unpinnable pages ie. long-term pins
> > will migrate the page.
> 
> I'm trying to understand check_and_migrate_movable_pages in gup.c. It
> doesn't look like the right way to migrate device pages. We may have to
> do something different there as well. So instead of changing
> is_pinnable_page, it maybe better to explicitly check for is_device_page
> or is_device_coherent_page in check_and_migrate_movable_pages to migrate
> it correctly, or just fail outright.

Yes, I think you're right. I was thinking check_and_migrate_movable_pages()
would work for coherent device pages. Now I see it won't because it assumes
they are lru pages and it tries to isolate them which will never succeed
because device pages aren't on a lru.

I think migrating them is the right thing to do for FOLL_LONGTERM though.

 - Alistair

> Thanks,
>   Felix
> 
> >
> >>> In the case of device-private pages this is enforced by the fact they never
> >>> have present pte's, so any attempt to GUP them results in a fault. But if I'm
> >>> understanding this series correctly that won't be the case for coherent device
> >>> pages right?
> >> Right.
> >>
> >> Regards,
> >>   Felix
> >>
> >>
> >>>> -		return is_device_private_page(page);
> >>>> +		return is_device_page(page);
> >>>>  	}
> >>>>  
> >>>>  	/* For file back page */
> >>>> @@ -2791,7 +2791,7 @@ EXPORT_SYMBOL(migrate_vma_setup);
> >>>>   *     handle_pte_fault()
> >>>>   *       do_anonymous_page()
> >>>>   * to map in an anonymous zero page but the struct page will be a ZONE_DEVICE
> >>>> - * private page.
> >>>> + * private or coherent page.
> >>>>   */
> >>>>  static void migrate_vma_insert_page(struct migrate_vma *migrate,
> >>>>  				    unsigned long addr,
> >>>> @@ -2867,10 +2867,15 @@ static void migrate_vma_insert_page(struct migrate_vma *migrate,
> >>>>  				swp_entry = make_readable_device_private_entry(
> >>>>  							page_to_pfn(page));
> >>>>  			entry = swp_entry_to_pte(swp_entry);
> >>>> +		} else if (is_device_page(page)) {
> >>> How about adding an explicit `is_device_coherent_page()` helper? It would make
> >>> the test more explicit that this is expected to handle just coherent pages and
> >>> I bet there will be future changes that need to differentiate between private
> >>> and coherent pages anyway.
> >>>
> >>>> +			entry = pte_mkold(mk_pte(page,
> >>>> +						 READ_ONCE(vma->vm_page_prot)));
> >>>> +			if (vma->vm_flags & VM_WRITE)
> >>>> +				entry = pte_mkwrite(pte_mkdirty(entry));
> >>>>  		} else {
> >>>>  			/*
> >>>> -			 * For now we only support migrating to un-addressable
> >>>> -			 * device memory.
> >>>> +			 * We support migrating to private and coherent types
> >>>> +			 * for device zone memory.
> >>>>  			 */
> >>>>  			pr_warn_once("Unsupported ZONE_DEVICE page type.\n");
> >>>>  			goto abort;
> >>>> @@ -2976,10 +2981,10 @@ void migrate_vma_pages(struct migrate_vma *migrate)
> >>>>  		mapping = page_mapping(page);
> >>>>  
> >>>>  		if (is_zone_device_page(newpage)) {
> >>>> -			if (is_device_private_page(newpage)) {
> >>>> +			if (is_device_page(newpage)) {
> >>>>  				/*
> >>>> -				 * For now only support private anonymous when
> >>>> -				 * migrating to un-addressable device memory.
> >>>> +				 * For now only support private and coherent
> >>>> +				 * anonymous when migrating to device memory.
> >>>>  				 */
> >>>>  				if (mapping) {
> >>>>  					migrate->src[i] &= ~MIGRATE_PFN_MIGRATE;
> >>>>
> >
> >
> 





WARNING: multiple messages have this Message-ID (diff)
From: Alistair Popple <apopple@nvidia.com>
To: <akpm@linux-foundation.org>, <linux-mm@kvack.org>,
	<rcampbell@nvidia.com>, <linux-ext4@vger.kernel.org>,
	<linux-xfs@vger.kernel.org>, Alex Sierra <alex.sierra@amd.com>,
	Felix Kuehling <felix.kuehling@amd.com>
Cc: <amd-gfx@lists.freedesktop.org>,
	<dri-devel@lists.freedesktop.org>, <jglisse@redhat.com>,
	<willy@infradead.org>, <jgg@nvidia.com>, <hch@lst.de>
Subject: Re: [PATCH v1 1/9] mm: add zone device coherent type memory support
Date: Tue, 23 Nov 2021 18:10:05 +1100	[thread overview]
Message-ID: <3642425.Elj8dHrGez@nvdebian> (raw)
In-Reply-To: <f45fb007-ccc4-4d09-b609-09faa81d3b81@amd.com>

On Tuesday, 23 November 2021 4:16:55 AM AEDT Felix Kuehling wrote:

[...]

> > Right, so long as my fix goes in I don't think there is anything wrong with
> > pinning device public pages. Agree that we should avoid FOLL_LONGTERM pins for
> > device memory though. I think the way to do that is update is_pinnable_page()
> > so we treat device pages the same as other unpinnable pages ie. long-term pins
> > will migrate the page.
> 
> I'm trying to understand check_and_migrate_movable_pages in gup.c. It
> doesn't look like the right way to migrate device pages. We may have to
> do something different there as well. So instead of changing
> is_pinnable_page, it maybe better to explicitly check for is_device_page
> or is_device_coherent_page in check_and_migrate_movable_pages to migrate
> it correctly, or just fail outright.

Yes, I think you're right. I was thinking check_and_migrate_movable_pages()
would work for coherent device pages. Now I see it won't because it assumes
they are lru pages and it tries to isolate them which will never succeed
because device pages aren't on a lru.

I think migrating them is the right thing to do for FOLL_LONGTERM though.

 - Alistair

> Thanks,
>   Felix
> 
> >
> >>> In the case of device-private pages this is enforced by the fact they never
> >>> have present pte's, so any attempt to GUP them results in a fault. But if I'm
> >>> understanding this series correctly that won't be the case for coherent device
> >>> pages right?
> >> Right.
> >>
> >> Regards,
> >>   Felix
> >>
> >>
> >>>> -		return is_device_private_page(page);
> >>>> +		return is_device_page(page);
> >>>>  	}
> >>>>  
> >>>>  	/* For file back page */
> >>>> @@ -2791,7 +2791,7 @@ EXPORT_SYMBOL(migrate_vma_setup);
> >>>>   *     handle_pte_fault()
> >>>>   *       do_anonymous_page()
> >>>>   * to map in an anonymous zero page but the struct page will be a ZONE_DEVICE
> >>>> - * private page.
> >>>> + * private or coherent page.
> >>>>   */
> >>>>  static void migrate_vma_insert_page(struct migrate_vma *migrate,
> >>>>  				    unsigned long addr,
> >>>> @@ -2867,10 +2867,15 @@ static void migrate_vma_insert_page(struct migrate_vma *migrate,
> >>>>  				swp_entry = make_readable_device_private_entry(
> >>>>  							page_to_pfn(page));
> >>>>  			entry = swp_entry_to_pte(swp_entry);
> >>>> +		} else if (is_device_page(page)) {
> >>> How about adding an explicit `is_device_coherent_page()` helper? It would make
> >>> the test more explicit that this is expected to handle just coherent pages and
> >>> I bet there will be future changes that need to differentiate between private
> >>> and coherent pages anyway.
> >>>
> >>>> +			entry = pte_mkold(mk_pte(page,
> >>>> +						 READ_ONCE(vma->vm_page_prot)));
> >>>> +			if (vma->vm_flags & VM_WRITE)
> >>>> +				entry = pte_mkwrite(pte_mkdirty(entry));
> >>>>  		} else {
> >>>>  			/*
> >>>> -			 * For now we only support migrating to un-addressable
> >>>> -			 * device memory.
> >>>> +			 * We support migrating to private and coherent types
> >>>> +			 * for device zone memory.
> >>>>  			 */
> >>>>  			pr_warn_once("Unsupported ZONE_DEVICE page type.\n");
> >>>>  			goto abort;
> >>>> @@ -2976,10 +2981,10 @@ void migrate_vma_pages(struct migrate_vma *migrate)
> >>>>  		mapping = page_mapping(page);
> >>>>  
> >>>>  		if (is_zone_device_page(newpage)) {
> >>>> -			if (is_device_private_page(newpage)) {
> >>>> +			if (is_device_page(newpage)) {
> >>>>  				/*
> >>>> -				 * For now only support private anonymous when
> >>>> -				 * migrating to un-addressable device memory.
> >>>> +				 * For now only support private and coherent
> >>>> +				 * anonymous when migrating to device memory.
> >>>>  				 */
> >>>>  				if (mapping) {
> >>>>  					migrate->src[i] &= ~MIGRATE_PFN_MIGRATE;
> >>>>
> >
> >
> 





  reply	other threads:[~2021-11-23 15:51 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-15 19:30 [PATCH v1 0/9] Add MEMORY_DEVICE_COHERENT for coherent device memory mapping Alex Sierra
2021-11-15 19:30 ` Alex Sierra
2021-11-15 19:30 ` [PATCH v1 1/9] mm: add zone device coherent type memory support Alex Sierra
2021-11-15 19:30   ` Alex Sierra
2021-11-17  9:50   ` Christoph Hellwig
2021-11-17  9:50     ` Christoph Hellwig
2021-11-18  6:53   ` Alistair Popple
2021-11-18  6:53     ` Alistair Popple
2021-11-18 18:59     ` Felix Kuehling
2021-11-18 18:59       ` Felix Kuehling
2021-11-22  2:40       ` Alistair Popple
2021-11-22  2:40         ` Alistair Popple
2021-11-22 17:16         ` Felix Kuehling
2021-11-22 17:16           ` Felix Kuehling
2021-11-23  7:10           ` Alistair Popple [this message]
2021-11-23  7:10             ` Alistair Popple
2021-11-15 19:30 ` [PATCH v1 2/9] mm: add device coherent vma selection for memory migration Alex Sierra
2021-11-15 19:30   ` Alex Sierra
2021-11-18  6:54   ` Alistair Popple
2021-11-18  6:54     ` Alistair Popple
2021-11-15 19:30 ` [PATCH v1 3/9] drm/amdkfd: add SPM support for SVM Alex Sierra
2021-11-15 19:30   ` Alex Sierra
2021-11-15 19:30 ` [PATCH v1 4/9] drm/amdkfd: coherent type as sys mem on migration to ram Alex Sierra
2021-11-15 19:30   ` Alex Sierra
2021-11-15 19:30 ` [PATCH v1 5/9] lib: test_hmm add ioctl to get zone device type Alex Sierra
2021-11-15 19:30   ` Alex Sierra
2021-11-15 19:30 ` [PATCH v1 6/9] lib: test_hmm add module param for " Alex Sierra
2021-11-15 19:30   ` Alex Sierra
2021-11-18  7:19   ` Alistair Popple
2021-11-18  7:19     ` Alistair Popple
2021-11-15 19:30 ` [PATCH v1 7/9] lib: add support for device coherent type in test_hmm Alex Sierra
2021-11-15 19:30   ` Alex Sierra
2021-11-25  2:12   ` Felix Kuehling
2021-11-25  2:12     ` Felix Kuehling
2021-11-15 19:30 ` [PATCH v1 8/9] tools: update hmm-test to support device coherent type Alex Sierra
2021-11-15 19:30   ` Alex Sierra
2021-11-15 19:30 ` [PATCH v1 9/9] tools: update test_hmm script to support SP config Alex Sierra
2021-11-15 19:30   ` 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=3642425.Elj8dHrGez@nvdebian \
    --to=apopple@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.sierra@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=felix.kuehling@amd.com \
    --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.