linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: ziy@nvidia.com, shy828301@gmail.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] mm: migrate: Correct the hugetlb migration stats
Date: Tue, 16 Nov 2021 14:03:48 +0800	[thread overview]
Message-ID: <71816b8f-93e5-5a2a-e616-d52a1c4d354c@linux.alibaba.com> (raw)
In-Reply-To: <20211115202146.473fff2404d7fb200dd48bd3@linux-foundation.org>



On 2021/11/16 12:21, Andrew Morton wrote:
> On Sun,  7 Nov 2021 16:57:26 +0800 Baolin Wang <baolin.wang@linux.alibaba.com> wrote:
> 
>> Correct the migration stats for hugetlb with using compound_nr() instead
>> of thp_nr_pages(),
> 
> It would be helpful to explain why using thp_nr_pages() was wrong.

Sure. Using thp_nr_pages() to get the number of subpages for a hugetlb 
is incorrect, since the number of subpages in te hugetlb is not always 
HPAGE_PMD_NR.

> And to explain the end user visible effects of this bug so we can

Actually not also user visible effect, but also hugetlb migration stats 
in kernel are incorrect. For he end user visible effects, like I 
described in patch 1,  the syscall move_pages() can return a 
non-migrated number larger than the number of pages the users tried to 
migrate, when a THP page is failed to migrate. This is confusing for users.

> decide whether -stable backporting is desirable.
> 
>> meanwhile change 'nr_failed_pages' to record the
>> number of normal pages failed to migrate, including THP and hugetlb,
>> and 'nr_succeeded' will record the number of normal pages migrated
>> successfully.
>>
>> Reviewed-by: Zi Yan <ziy@nvidia.com>
>> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
>> ---
>>   mm/migrate.c | 17 ++++++++---------
>>   1 file changed, 8 insertions(+), 9 deletions(-)
>>
>> diff --git a/mm/migrate.c b/mm/migrate.c
>> index 9aafdab..756190b 100644
>> --- a/mm/migrate.c
>> +++ b/mm/migrate.c
>> @@ -1436,9 +1436,9 @@ static inline int try_split_thp(struct page *page, struct page **page2,
>>    * It is caller's responsibility to call putback_movable_pages() to return pages
>>    * to the LRU or free list only if ret != 0.
>>    *
>> - * Returns the number of {normal page, THP} that were not migrated, or an error code.
>> - * The number of THP splits will be considered as the number of non-migrated THP,
>> - * no matter how many subpages of the THP are migrated successfully.
>> + * Returns the number of {normal page, THP, hugetlb} that were not migrated, or
> 
> This is a bit confusing.
> 
> If migrate_pages() failed to migrate one 4k pages then it returns 1,
> yes?

Yes.

> 
> But if migrate_pages() fails to migrate one 2MB hugepage then will it
> return 1 or will it return 512?

It will return 1 too.

> 
> And how can the caller actually _use_ this return value without knowing
> the above information?

IMHO other migration scenarios do not care about the actual non-migrated 
number of pages except the memory compaction migration, and I've fixed 
the memory compaction migration in patch 3.

So for the syscall move_pages(), we can change the return value to 
return the number of {normal page, THP, hugetlb} instead, and the number 
of THP splits will be considered as the number of non-migrated THP, no 
matter how many subpages of the THP are migrated successfully.

> In other words, perhaps this function should simply return pass/fail?

I think we've returned the successful migration pages through the 
parameter '*ret_succeeded' of the migrate_pages().


  reply	other threads:[~2021-11-16  6:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-07  8:57 [PATCH 0/3] Improve the " Baolin Wang
2021-11-07  8:57 ` [PATCH 1/3] mm: migrate: Fix the return value of migrate_pages() Baolin Wang
2021-11-09 18:10   ` Zi Yan
2021-11-23 18:46   ` Mike Kravetz
2021-11-24 10:30     ` Baolin Wang
2021-11-24 18:46       ` Mike Kravetz
2021-11-07  8:57 ` [PATCH 2/3] mm: migrate: Correct the hugetlb migration stats Baolin Wang
2021-11-16  4:21   ` Andrew Morton
2021-11-16  6:03     ` Baolin Wang [this message]
2021-11-23 19:25       ` Mike Kravetz
2021-11-24 10:47         ` Baolin Wang
2021-11-24 19:05           ` Mike Kravetz
2021-11-25  5:50             ` Baolin Wang
2021-11-07  8:57 ` [PATCH 3/3] mm: compaction: Fix the migration stats in trace_mm_compaction_migratepages() Baolin Wang

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=71816b8f-93e5-5a2a-e616-d52a1c4d354c@linux.alibaba.com \
    --to=baolin.wang@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=shy828301@gmail.com \
    --cc=ziy@nvidia.com \
    /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