lkml.org 
[lkml]   [2022]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2 1/2] mm/migrate_device.c: Copy pte dirty bit to page
Date

Alistair Popple <apopple@nvidia.com> writes:

> Peter Xu <peterx@redhat.com> writes:

>>> But it's kind of against a pure "optimization" in that if trylock failed,
>>> we'll clear the mpfn so the src[i] will be zero at last. Then will we
>>> directly give up on this page, or will we try to lock_page() again
>>> somewhere?
>
> That comment is out dated. We used to try locking the page again but
> that was removed by ab09243aa95a ("mm/migrate.c: remove
> MIGRATE_PFN_LOCKED"). See
> https://lkml.kernel.org/r/20211025041608.289017-1-apopple@nvidia.com
>
> Will post a clean-up for it.

By the way it's still an optimisation because in most cases we can avoid
calling try_to_migrate() and walking the rmap altogether if we install
the migration entries here. But I agree the comment is misleading.

>>> The future unmap op is also based on this "cpages", not "npages":
>>>
>>> if (args->cpages)
>>> migrate_vma_unmap(args);
>>>
>>> So I never figured out how this code really works. It'll be great if you
>>> could shed some light to it.
>>>
>>> Thanks,
>>>
>>> --
>>> Peter Xu

\
 
 \ /
  Last update: 2022-08-25 03:26    [W:0.156 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site