On 6/19/19 8:19 PM, Yang Shi wrote:
I think it does. There's:Yesïexactly.This is getting even more muddy TBH. Is there any reason that weI think it was already said that if pages can't be isolated, then
handle this problem during the isolation phase rather the migration?
migration phase won't process them, so they're just ignored.
However I think the patch is wrong to abort immediately whenIt is fine too. I don't see mbind semantics define how to handle such
encountering such page that cannot be isolated (AFAICS). IMHO it should
still try to migrate everything it can, and only then return -EIO.
case other than returning -EIO.
If MPOL_MF_MOVE is specified in flags, then the kernel *will attempt to
move all the existing pages* ... If MPOL_MF_STRICT is also specified,
then the call fails with the error *EIO if some pages could not be moved*
Aborting immediately would be against the attempt to move all.
By looking into the code, it looks not that easy as what I thought.I think we just need to remember if there was at least one page that
do_mbind() would check the return value of queue_pages_range(), it just
applies the policy and manipulates vmas as long as the return value is 0
(success), then migrate pages on the list. We could put the movable
pages on the list by not breaking immediately, but they will be ignored.
If we migrate the pages regardless of the return value, it may break the
policy since the policy will *not* be applied at all.
failed isolation or migration, but keep working, and in the end return
EIO if there was such page(s). I don't think it breaks the policy. Once
pages are allocated in a mapping, changing the policy is a best effort