From: Alistair Popple <apopple@nvidia.com>
To: <linux-mm@kvack.org>, <nouveau@lists.freedesktop.org>,
<bskeggs@redhat.com>, <akpm@linux-foundation.org>
Cc: <linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<kvm-ppc@vger.kernel.org>, <dri-devel@lists.freedesktop.org>,
<jhubbard@nvidia.com>, <rcampbell@nvidia.com>,
<jglisse@redhat.com>, "Alistair Popple" <apopple@nvidia.com>
Subject: [PATCH 4/9] Documentation: Add unmap and pin to HMM
Date: Tue, 9 Feb 2021 12:07:17 +1100 [thread overview]
Message-ID: <20210209010722.13839-5-apopple@nvidia.com> (raw)
In-Reply-To: <20210209010722.13839-1-apopple@nvidia.com>
Update the HMM documentation to include information on the unmap and pin
operation.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
---
Documentation/vm/hmm.rst | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index 09e28507f5b2..83234984f656 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -346,7 +346,15 @@ between device driver specific code and shared common code:
from the LRU (if system memory since device private pages are not on
the LRU), unmapped from the process, and a special migration PTE is
inserted in place of the original PTE.
- migrate_vma_setup() also clears the ``args->dst`` array.
+
+ A device driver may also initialise ``src`` entries with the
+ ``MIGRATE_PFN_PIN`` flag. This allows the device driver to unmap and pin
+ the existing system page in place whilst migrating page metadata to a
+ device private page. This leaves the page isolated from the LRU and gives
+ the device exclusive access to the page data without the need to migrate
+ data as any CPU access will trigger a fault. The device driver needs to
+ keep track of the ``src`` page as it effectively becomes the owner of
+ the page and needs to pass it in when remapping and unpinning the page.
3. The device driver allocates destination pages and copies source pages to
destination pages.
@@ -357,8 +365,8 @@ between device driver specific code and shared common code:
array for that page.
The driver then allocates either a device private struct page or a
- system memory page, locks the page with ``lock_page()``, and fills in the
- ``dst`` array entry with::
+ system memory page, locks the page with ``lock_page()``, and fills in
+ the ``dst`` array entry with::
dst[i] = migrate_pfn(page_to_pfn(dpage)) | MIGRATE_PFN_LOCKED;
@@ -373,6 +381,14 @@ between device driver specific code and shared common code:
destination or clear the destination device private memory if the pointer
is ``NULL`` meaning the source page was not populated in system memory.
+ Alternatively a driver that is remapping and unpinning a source page
+ obtained from a ``MIGRATE_PFN_PIN`` operation should lock the original
+ source page and pass it in along with the ``MIGRATE_PFN_UNPIN`` flag
+ without any need to copy data::
+
+ dst[i] = migrate_pfn(page_to_pfn(spage)) | MIGRATE_PFN_LOCKED
+ | MIGRATE_PFN_UNPIN;
+
4. ``migrate_vma_pages()``
This step is where the migration is actually "committed".
--
2.20.1
WARNING: multiple messages have this Message-ID (diff)
From: Alistair Popple <apopple@nvidia.com>
To: <linux-mm@kvack.org>, <nouveau@lists.freedesktop.org>,
<bskeggs@redhat.com>, <akpm@linux-foundation.org>
Cc: rcampbell@nvidia.com, linux-doc@vger.kernel.org,
Alistair Popple <apopple@nvidia.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
kvm-ppc@vger.kernel.org
Subject: [Nouveau] [PATCH 4/9] Documentation: Add unmap and pin to HMM
Date: Tue, 9 Feb 2021 12:07:17 +1100 [thread overview]
Message-ID: <20210209010722.13839-5-apopple@nvidia.com> (raw)
In-Reply-To: <20210209010722.13839-1-apopple@nvidia.com>
Update the HMM documentation to include information on the unmap and pin
operation.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
---
Documentation/vm/hmm.rst | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index 09e28507f5b2..83234984f656 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -346,7 +346,15 @@ between device driver specific code and shared common code:
from the LRU (if system memory since device private pages are not on
the LRU), unmapped from the process, and a special migration PTE is
inserted in place of the original PTE.
- migrate_vma_setup() also clears the ``args->dst`` array.
+
+ A device driver may also initialise ``src`` entries with the
+ ``MIGRATE_PFN_PIN`` flag. This allows the device driver to unmap and pin
+ the existing system page in place whilst migrating page metadata to a
+ device private page. This leaves the page isolated from the LRU and gives
+ the device exclusive access to the page data without the need to migrate
+ data as any CPU access will trigger a fault. The device driver needs to
+ keep track of the ``src`` page as it effectively becomes the owner of
+ the page and needs to pass it in when remapping and unpinning the page.
3. The device driver allocates destination pages and copies source pages to
destination pages.
@@ -357,8 +365,8 @@ between device driver specific code and shared common code:
array for that page.
The driver then allocates either a device private struct page or a
- system memory page, locks the page with ``lock_page()``, and fills in the
- ``dst`` array entry with::
+ system memory page, locks the page with ``lock_page()``, and fills in
+ the ``dst`` array entry with::
dst[i] = migrate_pfn(page_to_pfn(dpage)) | MIGRATE_PFN_LOCKED;
@@ -373,6 +381,14 @@ between device driver specific code and shared common code:
destination or clear the destination device private memory if the pointer
is ``NULL`` meaning the source page was not populated in system memory.
+ Alternatively a driver that is remapping and unpinning a source page
+ obtained from a ``MIGRATE_PFN_PIN`` operation should lock the original
+ source page and pass it in along with the ``MIGRATE_PFN_UNPIN`` flag
+ without any need to copy data::
+
+ dst[i] = migrate_pfn(page_to_pfn(spage)) | MIGRATE_PFN_LOCKED
+ | MIGRATE_PFN_UNPIN;
+
4. ``migrate_vma_pages()``
This step is where the migration is actually "committed".
--
2.20.1
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
WARNING: multiple messages have this Message-ID (diff)
From: Alistair Popple <apopple@nvidia.com>
To: <linux-mm@kvack.org>, <nouveau@lists.freedesktop.org>,
<bskeggs@redhat.com>, <akpm@linux-foundation.org>
Cc: rcampbell@nvidia.com, linux-doc@vger.kernel.org,
jhubbard@nvidia.com, Alistair Popple <apopple@nvidia.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
jglisse@redhat.com, kvm-ppc@vger.kernel.org
Subject: [PATCH 4/9] Documentation: Add unmap and pin to HMM
Date: Tue, 9 Feb 2021 12:07:17 +1100 [thread overview]
Message-ID: <20210209010722.13839-5-apopple@nvidia.com> (raw)
In-Reply-To: <20210209010722.13839-1-apopple@nvidia.com>
Update the HMM documentation to include information on the unmap and pin
operation.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
---
Documentation/vm/hmm.rst | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index 09e28507f5b2..83234984f656 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -346,7 +346,15 @@ between device driver specific code and shared common code:
from the LRU (if system memory since device private pages are not on
the LRU), unmapped from the process, and a special migration PTE is
inserted in place of the original PTE.
- migrate_vma_setup() also clears the ``args->dst`` array.
+
+ A device driver may also initialise ``src`` entries with the
+ ``MIGRATE_PFN_PIN`` flag. This allows the device driver to unmap and pin
+ the existing system page in place whilst migrating page metadata to a
+ device private page. This leaves the page isolated from the LRU and gives
+ the device exclusive access to the page data without the need to migrate
+ data as any CPU access will trigger a fault. The device driver needs to
+ keep track of the ``src`` page as it effectively becomes the owner of
+ the page and needs to pass it in when remapping and unpinning the page.
3. The device driver allocates destination pages and copies source pages to
destination pages.
@@ -357,8 +365,8 @@ between device driver specific code and shared common code:
array for that page.
The driver then allocates either a device private struct page or a
- system memory page, locks the page with ``lock_page()``, and fills in the
- ``dst`` array entry with::
+ system memory page, locks the page with ``lock_page()``, and fills in
+ the ``dst`` array entry with::
dst[i] = migrate_pfn(page_to_pfn(dpage)) | MIGRATE_PFN_LOCKED;
@@ -373,6 +381,14 @@ between device driver specific code and shared common code:
destination or clear the destination device private memory if the pointer
is ``NULL`` meaning the source page was not populated in system memory.
+ Alternatively a driver that is remapping and unpinning a source page
+ obtained from a ``MIGRATE_PFN_PIN`` operation should lock the original
+ source page and pass it in along with the ``MIGRATE_PFN_UNPIN`` flag
+ without any need to copy data::
+
+ dst[i] = migrate_pfn(page_to_pfn(spage)) | MIGRATE_PFN_LOCKED
+ | MIGRATE_PFN_UNPIN;
+
4. ``migrate_vma_pages()``
This step is where the migration is actually "committed".
--
2.20.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Alistair Popple <apopple@nvidia.com>
To: linux-mm@kvack.org, nouveau@lists.freedesktop.org,
bskeggs@redhat.com, akpm@linux-foundation.org
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm-ppc@vger.kernel.org, dri-devel@lists.freedesktop.org,
jhubbard@nvidia.com, rcampbell@nvidia.com, jglisse@redhat.com,
Alistair Popple <apopple@nvidia.com>
Subject: [PATCH 4/9] Documentation: Add unmap and pin to HMM
Date: Tue, 09 Feb 2021 01:07:17 +0000 [thread overview]
Message-ID: <20210209010722.13839-5-apopple@nvidia.com> (raw)
In-Reply-To: <20210209010722.13839-1-apopple@nvidia.com>
Update the HMM documentation to include information on the unmap and pin
operation.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
---
Documentation/vm/hmm.rst | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index 09e28507f5b2..83234984f656 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -346,7 +346,15 @@ between device driver specific code and shared common code:
from the LRU (if system memory since device private pages are not on
the LRU), unmapped from the process, and a special migration PTE is
inserted in place of the original PTE.
- migrate_vma_setup() also clears the ``args->dst`` array.
+
+ A device driver may also initialise ``src`` entries with the
+ ``MIGRATE_PFN_PIN`` flag. This allows the device driver to unmap and pin
+ the existing system page in place whilst migrating page metadata to a
+ device private page. This leaves the page isolated from the LRU and gives
+ the device exclusive access to the page data without the need to migrate
+ data as any CPU access will trigger a fault. The device driver needs to
+ keep track of the ``src`` page as it effectively becomes the owner of
+ the page and needs to pass it in when remapping and unpinning the page.
3. The device driver allocates destination pages and copies source pages to
destination pages.
@@ -357,8 +365,8 @@ between device driver specific code and shared common code:
array for that page.
The driver then allocates either a device private struct page or a
- system memory page, locks the page with ``lock_page()``, and fills in the
- ``dst`` array entry with::
+ system memory page, locks the page with ``lock_page()``, and fills in
+ the ``dst`` array entry with::
dst[i] = migrate_pfn(page_to_pfn(dpage)) | MIGRATE_PFN_LOCKED;
@@ -373,6 +381,14 @@ between device driver specific code and shared common code:
destination or clear the destination device private memory if the pointer
is ``NULL`` meaning the source page was not populated in system memory.
+ Alternatively a driver that is remapping and unpinning a source page
+ obtained from a ``MIGRATE_PFN_PIN`` operation should lock the original
+ source page and pass it in along with the ``MIGRATE_PFN_UNPIN`` flag
+ without any need to copy data::
+
+ dst[i] = migrate_pfn(page_to_pfn(spage)) | MIGRATE_PFN_LOCKED
+ | MIGRATE_PFN_UNPIN;
+
4. ``migrate_vma_pages()``
This step is where the migration is actually "committed".
--
2.20.1
next prev parent reply other threads:[~2021-02-09 1:11 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-09 1:07 [PATCH 0/9] Add support for SVM atomics in Nouveau Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` [Nouveau] " Alistair Popple
2021-02-09 1:07 ` [PATCH 1/9] mm/migrate.c: Always allow device private pages to migrate Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` [Nouveau] " Alistair Popple
2021-02-09 13:39 ` Jason Gunthorpe
2021-02-09 13:39 ` Jason Gunthorpe
2021-02-09 13:39 ` Jason Gunthorpe
2021-02-09 13:39 ` [Nouveau] " Jason Gunthorpe
2021-02-10 3:40 ` Alistair Popple
2021-02-10 3:40 ` Alistair Popple
2021-02-10 3:40 ` Alistair Popple
2021-02-10 3:40 ` [Nouveau] " Alistair Popple
2021-02-10 12:56 ` Jason Gunthorpe
2021-02-10 12:56 ` Jason Gunthorpe
2021-02-10 12:56 ` Jason Gunthorpe
2021-02-10 12:56 ` [Nouveau] " Jason Gunthorpe
2021-02-09 1:07 ` [PATCH 2/9] mm/migrate.c: Allow pfn flags to be passed to migrate_vma_setup() Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` [Nouveau] " Alistair Popple
2021-02-09 1:07 ` [PATCH 3/9] mm/migrate: Add a unmap and pin migration mode Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` [Nouveau] " Alistair Popple
2021-02-09 1:07 ` Alistair Popple [this message]
2021-02-09 1:07 ` [PATCH 4/9] Documentation: Add unmap and pin to HMM Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` [Nouveau] " Alistair Popple
2021-02-09 1:07 ` [PATCH 5/9] hmm-tests: Add test for unmap and pin Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` [Nouveau] " Alistair Popple
2021-02-09 1:07 ` [PATCH 6/9] nouveau/dmem: Only map migrating pages Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` [Nouveau] " Alistair Popple
2021-02-09 1:07 ` [PATCH 7/9] nouveau/svm: Refactor nouveau_range_fault Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` [Nouveau] " Alistair Popple
2021-02-09 1:07 ` [PATCH 8/9] nouveau/dmem: Add support for multiple page types Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` [Nouveau] " Alistair Popple
2021-02-09 1:07 ` [PATCH 9/9] nouveau/svm: Implement atomic SVM access Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` Alistair Popple
2021-02-09 1:07 ` [Nouveau] " Alistair Popple
2021-02-09 10:27 ` [PATCH 0/9] Add support for SVM atomics in Nouveau Daniel Vetter
2021-02-09 10:27 ` Daniel Vetter
2021-02-09 10:27 ` Daniel Vetter
2021-02-09 10:27 ` [Nouveau] " Daniel Vetter
2021-02-09 10:27 ` Daniel Vetter
2021-02-09 12:57 ` Alistair Popple
2021-02-09 12:57 ` Alistair Popple
2021-02-09 12:57 ` Alistair Popple
2021-02-09 12:57 ` [Nouveau] " Alistair Popple
2021-02-09 13:35 ` Jason Gunthorpe
2021-02-09 13:35 ` Jason Gunthorpe
2021-02-09 13:35 ` Jason Gunthorpe
2021-02-09 13:35 ` [Nouveau] " Jason Gunthorpe
2021-02-09 13:39 ` Daniel Vetter
2021-02-09 13:39 ` Daniel Vetter
2021-02-09 13:39 ` Daniel Vetter
2021-02-09 13:39 ` [Nouveau] " Daniel Vetter
2021-02-09 13:39 ` Daniel Vetter
2021-02-09 13:44 ` Jason Gunthorpe
2021-02-09 13:44 ` Jason Gunthorpe
2021-02-09 13:44 ` Jason Gunthorpe
2021-02-09 13:44 ` [Nouveau] " Jason Gunthorpe
2021-02-09 21:17 ` Jerome Glisse
2021-02-09 21:17 ` Jerome Glisse
2021-02-09 21:17 ` Jerome Glisse
2021-02-09 21:17 ` [Nouveau] " Jerome Glisse
2021-02-10 17:56 ` Jason Gunthorpe
2021-02-10 17:56 ` Jason Gunthorpe
2021-02-10 17:56 ` Jason Gunthorpe
2021-02-10 17:56 ` [Nouveau] " Jason Gunthorpe
2021-02-09 13:37 ` Daniel Vetter
2021-02-09 13:37 ` Daniel Vetter
2021-02-09 13:37 ` Daniel Vetter
2021-02-09 13:37 ` [Nouveau] " Daniel Vetter
2021-02-09 13:37 ` Daniel Vetter
2021-02-09 20:53 ` John Hubbard
2021-02-09 20:53 ` John Hubbard
2021-02-09 20:53 ` John Hubbard
2021-02-09 20:53 ` [Nouveau] " John Hubbard
2021-02-10 12:59 ` Daniel Vetter
2021-02-10 12:59 ` Daniel Vetter
2021-02-10 12:59 ` Daniel Vetter
2021-02-10 12:59 ` [Nouveau] " Daniel Vetter
2021-02-11 2:26 ` John Hubbard
2021-02-11 2:26 ` John Hubbard
2021-02-11 2:26 ` John Hubbard
2021-02-11 2:26 ` [Nouveau] " John Hubbard
2021-02-10 17:59 ` Jason Gunthorpe
2021-02-10 17:59 ` Jason Gunthorpe
2021-02-10 17:59 ` Jason Gunthorpe
2021-02-10 17:59 ` [Nouveau] " Jason Gunthorpe
2021-02-11 7:55 ` Christoph Hellwig
2021-02-11 7:55 ` [Nouveau] " Christoph Hellwig
2021-02-17 23:00 ` Alistair Popple
2021-02-17 23:00 ` Alistair Popple
2021-02-17 23:00 ` Alistair Popple
2021-02-17 23:00 ` [Nouveau] " Alistair Popple
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=20210209010722.13839-5-apopple@nvidia.com \
--to=apopple@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=bskeggs@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jglisse@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nouveau@lists.freedesktop.org \
--cc=rcampbell@nvidia.com \
/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.