All of lore.kernel.org
 help / color / mirror / Atom feed
From: Evgeny Baskakov <ebaskakov@nvidia.com>
To: "Jérôme Glisse" <jglisse@redhat.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: John Hubbard <jhubbard@nvidia.com>,
	David Nellans <dnellans@nvidia.com>,
	Mark Hairgrove <mhairgrove@nvidia.com>,
	Sherry Cheung <SCheung@nvidia.com>,
	Subhash Gutti <sgutti@nvidia.com>
Subject: RE: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4
Date: Tue, 27 Jun 2017 00:07:42 +0000	[thread overview]
Message-ID: <fa402b70fa9d418ebf58a26a454abd06@HQMAIL103.nvidia.com> (raw)
In-Reply-To: <20170522165206.6284-13-jglisse@redhat.com>

On Monday, May 22, 2017 9:52 AM, Jérôme Glisse wrote:
[...]

+ * The alloc_and_copy() callback happens once all source pages have 
+been locked,
+ * unmapped and checked (checked whether pinned or not). All pages that 
+can be
+ * migrated will have an entry in the src array set with the pfn value 
+of the
+ * page and with the MIGRATE_PFN_VALID and MIGRATE_PFN_MIGRATE flag set 
+(other
+ * flags might be set but should be ignored by the callback).
+ *
+ * The alloc_and_copy() callback can then allocate destination memory 
+and copy
+ * source memory to it for all those entries (ie with MIGRATE_PFN_VALID 
+and
+ * MIGRATE_PFN_MIGRATE flag set). Once these are allocated and copied, 
+the
+ * callback must update each corresponding entry in the dst array with 
+the pfn
+ * value of the destination page and with the MIGRATE_PFN_VALID and
+ * MIGRATE_PFN_LOCKED flags set (destination pages must have their 
+struct pages
+ * locked, via lock_page()).
+ *
+ * At this point the alloc_and_copy() callback is done and returns.
+ *
+ * Note that the callback does not have to migrate all the pages that 
+are
+ * marked with MIGRATE_PFN_MIGRATE flag in src array unless this is a 
+migration
+ * from device memory to system memory (ie the MIGRATE_PFN_DEVICE flag 
+is also
+ * set in the src array entry). If the device driver cannot migrate a 
+device
+ * page back to system memory, then it must set the corresponding dst 
+array
+ * entry to MIGRATE_PFN_ERROR. This will trigger a SIGBUS if CPU tries 
+to
+ * access any of the virtual addresses originally backed by this page. 
+Because
+ * a SIGBUS is such a severe result for the userspace process, the 
+device
+ * driver should avoid setting MIGRATE_PFN_ERROR unless it is really in 
+an
+ * unrecoverable state.
+ *
+ * THE alloc_and_copy() CALLBACK MUST NOT CHANGE ANY OF THE SRC ARRAY 
+ENTRIES
+ * OR BAD THINGS WILL HAPPEN !
+ *

Hi Jerome,

The documentation shown above doesn't tell what the alloc_and_copy callback should do for source pages that have not been allocated yet. Instead, it unconditionally suggests checking if the MIGRATE_PFN_VALID and MIGRATE_PFN_MIGRATE flags are set.

Based on my testing and looking in the source code, I see that for such pages the respective 'src' PFN entries are always set to 0 without any flags.

The sample driver specifically handles that by checking if there's no page in the 'src' entry, and ignores any flags in such case:

	struct page *spage = migrate_pfn_to_page(*src_pfns);
	...
	if (spage && !(*src_pfns & MIGRATE_PFN_MIGRATE))
		continue;

	if (spage && (*src_pfns & MIGRATE_PFN_DEVICE)) {

I would like to suggest reflecting that in the documentation. Or, which would be more logical, migrate_vma could keep the zero in the PFN entries for not allocated pages, but set the MIGRATE_PFN_MIGRATE flag anyway.

Thanks!

Evgeny Baskakov
NVIDIA

  parent reply	other threads:[~2017-06-27  0:07 UTC|newest]

Thread overview: 128+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-22 16:51 [HMM 00/15] HMM (Heterogeneous Memory Management) v22 Jérôme Glisse
2017-05-22 16:51 ` Jérôme Glisse
2017-05-22 16:51 ` [HMM 01/15] hmm: heterogeneous memory management documentation Jérôme Glisse
2017-05-22 16:51   ` Jérôme Glisse
2017-05-22 16:51 ` [HMM 02/15] mm/hmm: heterogeneous memory management (HMM for short) v3 Jérôme Glisse
2017-05-22 16:51   ` Jérôme Glisse
2017-05-22 16:51 ` [HMM 03/15] mm/hmm/mirror: mirror process address space on device with HMM helpers v3 Jérôme Glisse
2017-05-22 16:51   ` Jérôme Glisse
2017-05-22 16:51 ` [HMM 04/15] mm/hmm/mirror: helper to snapshot CPU page table v3 Jérôme Glisse
2017-05-22 16:51   ` Jérôme Glisse
2017-05-22 16:51 ` [HMM 05/15] mm/hmm/mirror: device page fault handler Jérôme Glisse
2017-05-22 16:51   ` Jérôme Glisse
2017-05-22 16:51 ` [HMM 06/15] mm/memory_hotplug: introduce add_pages Jérôme Glisse
2017-05-22 16:51   ` Jérôme Glisse
2017-05-22 16:51 ` [HMM 07/15] mm/ZONE_DEVICE: new type of ZONE_DEVICE for unaddressable memory v2 Jérôme Glisse
2017-05-22 16:51   ` Jérôme Glisse
2017-05-22 21:17   ` Dan Williams
2017-05-22 21:17     ` Dan Williams
2017-05-23 21:36     ` [HMM 07/18] mm/ZONE_DEVICE: new type of ZONE_DEVICE for unaddressable memory v3 Jérôme Glisse
2017-05-23 21:36       ` Jérôme Glisse
2017-05-23  8:36   ` [HMM 07/15] mm/ZONE_DEVICE: new type of ZONE_DEVICE for unaddressable memory v2 kbuild test robot
2017-05-23  8:36     ` kbuild test robot
2017-05-22 16:51 ` [HMM 08/15] mm/ZONE_DEVICE: special case put_page() for device private pages Jérôme Glisse
2017-05-22 16:51   ` Jérôme Glisse
2017-05-22 19:29   ` Dan Williams
2017-05-22 19:29     ` Dan Williams
2017-05-22 20:14     ` Jerome Glisse
2017-05-22 20:14       ` Jerome Glisse
2017-05-22 20:19       ` Dan Williams
2017-05-22 20:19         ` Dan Williams
2017-05-22 21:14         ` Jerome Glisse
2017-05-22 21:14           ` Jerome Glisse
2017-05-22 20:22       ` Hugh Dickins
2017-05-22 20:22         ` Hugh Dickins
2017-05-22 21:17         ` Jerome Glisse
2017-05-22 21:17           ` Jerome Glisse
2017-05-23  9:34   ` kbuild test robot
2017-05-23  9:34     ` kbuild test robot
2017-05-23 13:23   ` Kirill A. Shutemov
2017-05-23 13:23     ` Kirill A. Shutemov
2017-05-23 21:37     ` [HMM 08/18] mm/ZONE_DEVICE: special case put_page() for device private pages v2 Jérôme Glisse
2017-05-23 21:37       ` Jérôme Glisse
2017-05-22 16:52 ` [HMM 09/15] mm/hmm/devmem: device memory hotplug using ZONE_DEVICE v4 Jérôme Glisse
2017-05-22 16:52   ` Jérôme Glisse
2017-05-23 21:37   ` [HMM 09/18] mm/hmm/devmem: device memory hotplug using ZONE_DEVICE v5 Jérôme Glisse
2017-05-23 21:37     ` Jérôme Glisse
2017-05-22 16:52 ` [HMM 10/15] mm/hmm/devmem: dummy HMM device for ZONE_DEVICE memory v3 Jérôme Glisse
2017-05-22 16:52   ` Jérôme Glisse
2017-05-22 16:52 ` [HMM 11/15] mm/migrate: new migrate mode MIGRATE_SYNC_NO_COPY Jérôme Glisse
2017-05-22 16:52   ` Jérôme Glisse
2017-05-22 16:52 ` [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4 Jérôme Glisse
2017-05-22 16:52   ` Jérôme Glisse
2017-05-23 18:07   ` Reza Arbab
2017-05-23 18:07     ` Reza Arbab
2017-06-27  0:07   ` Evgeny Baskakov [this message]
2017-06-30 23:19     ` Evgeny Baskakov
2017-06-30 23:19       ` Evgeny Baskakov
2017-07-01  0:57       ` Jerome Glisse
2017-07-01  0:57         ` Jerome Glisse
2017-07-01  2:06         ` Evgeny Baskakov
2017-07-01  2:06           ` Evgeny Baskakov
2017-07-10 22:59         ` Evgeny Baskakov
2017-07-10 23:43           ` Jerome Glisse
2017-07-10 23:43             ` Jerome Glisse
2017-07-11  0:17             ` Evgeny Baskakov
2017-07-11  0:17               ` Evgeny Baskakov
2017-07-11  0:54               ` Jerome Glisse
2017-07-11  0:54                 ` Jerome Glisse
2017-07-20 21:05                 ` Evgeny Baskakov
2017-07-20 21:05                   ` Evgeny Baskakov
2017-07-10 23:44         ` Evgeny Baskakov
2017-07-11 18:29           ` Jerome Glisse
2017-07-11 18:29             ` Jerome Glisse
2017-07-11 18:42             ` Evgeny Baskakov
2017-07-11 18:42               ` Evgeny Baskakov
2017-07-11 18:49               ` Jerome Glisse
2017-07-11 18:49                 ` Jerome Glisse
2017-07-11 19:35                 ` Evgeny Baskakov
2017-07-11 19:35                   ` Evgeny Baskakov
2017-07-13 20:16                   ` Jerome Glisse
2017-07-13 20:16                     ` Jerome Glisse
2017-07-14  5:32                     ` Evgeny Baskakov
2017-07-14  5:32                       ` Evgeny Baskakov
2017-07-14 19:43                     ` Evgeny Baskakov
2017-07-15  0:55                       ` Jerome Glisse
2017-07-15  0:55                         ` Jerome Glisse
2017-07-15  5:04                         ` Evgeny Baskakov
2017-07-15  5:04                           ` Evgeny Baskakov
2017-07-21  1:00                         ` Evgeny Baskakov
2017-07-21  1:00                           ` Evgeny Baskakov
2017-07-21  1:33                           ` Jerome Glisse
2017-07-21  1:33                             ` Jerome Glisse
2017-07-21 22:01                             ` Evgeny Baskakov
2017-07-21 22:01                               ` Evgeny Baskakov
2017-07-25 22:45                             ` Evgeny Baskakov
2017-07-25 22:45                               ` Evgeny Baskakov
2017-07-26 19:14                               ` Jerome Glisse
2017-07-26 19:14                                 ` Jerome Glisse
2017-05-22 16:52 ` [HMM 13/15] mm/migrate: migrate_vma() unmap page from vma while collecting pages Jérôme Glisse
2017-05-22 16:52   ` Jérôme Glisse
2017-05-22 16:52 ` [HMM 14/15] mm/migrate: support un-addressable ZONE_DEVICE page in migration v2 Jérôme Glisse
2017-05-22 16:52   ` Jérôme Glisse
2017-05-22 16:52 ` [HMM 15/15] mm/migrate: allow migrate_vma() to alloc new page on empty entry v2 Jérôme Glisse
2017-05-22 16:52   ` Jérôme Glisse
2017-05-23 22:02 ` [HMM 00/15] HMM (Heterogeneous Memory Management) v22 Jerome Glisse
2017-05-23 22:02   ` Jerome Glisse
2017-05-23 22:05   ` Andrew Morton
2017-05-23 22:05     ` Andrew Morton
2017-05-24  1:55 ` Balbir Singh
2017-05-24  1:55   ` Balbir Singh
2017-05-24 17:53   ` Jerome Glisse
2017-05-24 17:53     ` Jerome Glisse
2017-06-01  2:04     ` Balbir Singh
2017-06-01  2:04       ` Balbir Singh
2017-06-01 22:38       ` Jerome Glisse
2017-06-01 22:38         ` Jerome Glisse
2017-06-03  9:18         ` Balbir Singh
2017-06-03  9:18           ` Balbir Singh
2017-05-24 17:20 [HMM 00/15] HMM (Heterogeneous Memory Management) v23 Jérôme Glisse
2017-05-24 17:20 ` [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4 Jérôme Glisse
2017-05-24 17:20   ` Jérôme Glisse
2017-05-31  3:59   ` Balbir Singh
2017-05-31  3:59     ` Balbir Singh
2017-06-01 22:35     ` Jerome Glisse
2017-06-01 22:35       ` Jerome Glisse
2017-06-07  9:02       ` Balbir Singh
2017-06-07  9:02         ` Balbir Singh
2017-06-07 14:06         ` Jerome Glisse
2017-06-07 14:06           ` Jerome Glisse

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=fa402b70fa9d418ebf58a26a454abd06@HQMAIL103.nvidia.com \
    --to=ebaskakov@nvidia.com \
    --cc=SCheung@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=dnellans@nvidia.com \
    --cc=jglisse@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhairgrove@nvidia.com \
    --cc=sgutti@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.