Messages in this thread | | | From | Alistair Popple <> | Subject | Re: [PATCH v2 1/2] mm/migrate_device.c: Copy pte dirty bit to page | Date | Thu, 25 Aug 2022 11:24:03 +1000 |
| |
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
| |