lkml.org 
[lkml]   [2017]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4
From
Date
On 6/26/17 5:07 PM, Evgeny Baskakov wrote:

> 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
>

Hi Jerome,

It seems that the kernel can pass 0 in src_pfns for pages that it cannot
migrate (i.e. the kernel knows that they cannot migrate prior to calling
alloc_and_copy).

So, a zero in src_pfns can mean either "the page is not allocated yet"
or "the page cannot migrate".

Can migrate_vma set the MIGRATE_PFN_MIGRATE flag for not allocated
pages? On the driver side it is difficult to differentiate between the
cases.

Thanks!

Evgeny Baskakov
NVIDIA

\
 
 \ /
  Last update: 2017-07-01 01:20    [W:0.154 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site