From: Yang Shi <yang.shi@linux.alibaba.com>
To: Vlastimil Babka <vbabka@suse.cz>,
mhocko@kernel.org, mgorman@techsingularity.net,
akpm@linux-foundation.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [v2 PATCH 2/2] mm: mempolicy: handle vma with unmovable pages mapped correctly in mbind
Date: Wed, 17 Jul 2019 11:23:16 -0700 [thread overview]
Message-ID: <3197a7df-c7bc-2bac-3d40-dbfc97d4a909@linux.alibaba.com> (raw)
In-Reply-To: <9defdc16-c825-05b7-b394-abdf39000220@linux.alibaba.com>
On 7/16/19 10:28 AM, Yang Shi wrote:
>
>
> On 7/16/19 5:07 AM, Vlastimil Babka wrote:
>> On 6/22/19 2:20 AM, Yang Shi wrote:
>>> @@ -969,10 +975,21 @@ static long do_get_mempolicy(int *policy,
>>> nodemask_t *nmask,
>>> /*
>>> * page migration, thp tail pages can be passed.
>>> */
>>> -static void migrate_page_add(struct page *page, struct list_head
>>> *pagelist,
>>> +static int migrate_page_add(struct page *page, struct list_head
>>> *pagelist,
>>> unsigned long flags)
>>> {
>>> struct page *head = compound_head(page);
>>> +
>>> + /*
>>> + * Non-movable page may reach here. And, there may be
>>> + * temporaty off LRU pages or non-LRU movable pages.
>>> + * Treat them as unmovable pages since they can't be
>>> + * isolated, so they can't be moved at the moment. It
>>> + * should return -EIO for this case too.
>>> + */
>>> + if (!PageLRU(head) && (flags & MPOL_MF_STRICT))
>>> + return -EIO;
>>> +
>> Hm but !PageLRU() is not the only way why queueing for migration can
>> fail, as can be seen from the rest of the function. Shouldn't all cases
>> be reported?
>
> Do you mean the shared pages and isolation failed pages? I'm not sure
> whether we should consider these cases break the semantics or not, so
> I leave them as they are. But, strictly speaking they should be
> reported too, at least for the isolation failed page.
By reading mbind man page, it says:
If MPOL_MF_MOVE is specified in flags, then the kernel will attempt to
move all the existing pages in the memory range so that they follow the
policy. Pages that are shared with other processes will not be moved.
If MPOL_MF_STRICT is also specified, then the call fails with the error
EIO if some pages could not be moved.
It looks the code already handles shared page correctly, we just need
return -EIO for isolation failed page if MPOL_MF_STRICT is specified.
>
> Thanks,
> Yang
>
>>
>>> /*
>>> * Avoid migrating a page that is shared with others.
>>> */
>>> @@ -984,6 +1001,8 @@ static void migrate_page_add(struct page *page,
>>> struct list_head *pagelist,
>>> hpage_nr_pages(head));
>>> }
>>> }
>>> +
>>> + return 0;
>>> }
>>> /* page allocation callback for NUMA node migration */
>>> @@ -1186,9 +1205,10 @@ static struct page *new_page(struct page
>>> *page, unsigned long start)
>>> }
>>> #else
>>> -static void migrate_page_add(struct page *page, struct list_head
>>> *pagelist,
>>> +static int migrate_page_add(struct page *page, struct list_head
>>> *pagelist,
>>> unsigned long flags)
>>> {
>>> + return -EIO;
>>> }
>>> int do_migrate_pages(struct mm_struct *mm, const nodemask_t *from,
>>>
>
next prev parent reply other threads:[~2019-07-17 18:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-22 0:20 [v2 PATCH 0/2] mm: mempolicy: fix mbind()'s inconsistent behavior for unmovable pages Yang Shi
2019-06-22 0:20 ` [v2 PATCH 1/2] mm: mempolicy: make the behavior consistent when MPOL_MF_MOVE* and MPOL_MF_STRICT were specified Yang Shi
2019-07-16 8:12 ` Vlastimil Babka
2019-07-16 8:47 ` Vlastimil Babka
2019-07-16 17:19 ` Yang Shi
2019-07-16 17:18 ` Yang Shi
2019-07-17 10:55 ` Vlastimil Babka
2019-07-17 16:51 ` Yang Shi
2019-06-22 0:20 ` [v2 PATCH 2/2] mm: mempolicy: handle vma with unmovable pages mapped correctly in mbind Yang Shi
2019-07-16 12:07 ` Vlastimil Babka
2019-07-16 17:28 ` Yang Shi
2019-07-17 18:23 ` Yang Shi [this message]
2019-07-17 18:39 ` Yang Shi
2019-07-17 18:50 ` Vlastimil Babka
2019-07-17 19:25 ` Yang Shi
2019-07-15 22:22 ` [v2 PATCH 0/2] mm: mempolicy: fix mbind()'s inconsistent behavior for unmovable pages Andrew Morton
2019-07-15 23:51 ` Yang Shi
2019-07-15 23:54 ` Yang Shi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3197a7df-c7bc-2bac-3d40-dbfc97d4a909@linux.alibaba.com \
--to=yang.shi@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox