Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4

[Evgeny Baskakov]

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