linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Mike Kravetz <mike.kravetz@oracle.com>,
	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: Thu, 25 Nov 2021 13:50:25 +0800	[thread overview]
Message-ID: <141bdfc6-f898-3cc3-f692-726c5f6cb74d@linux.alibaba.com> (raw)
In-Reply-To: <7423472b-a6d4-4b37-0953-24b11aba2fad@oracle.com>



On 2021/11/25 3:05, Mike Kravetz wrote:
> On 11/24/21 02:47, Baolin Wang wrote:
>>
>>
>> On 2021/11/24 3:25, Mike Kravetz wrote:
>>> On 11/15/21 22:03, Baolin Wang wrote:
>>>> 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:
>>>>>
>>> I 'think' this is OK since the behavior is not really defined today.  But, we
>>> are changing user visible output.
>>
>> Actually we did not change the user visible output for a hugetlb migration. Since we still return the number of hugetlb failed to migrate as before (though previous hugetlb behavior is not reasonable), not the number of hguetlb subpages. We just correct the hugetlb migration stats for the hugetlb in kernel, like PGMIGRATE_SUCCESS/FAIL stats.
>>
> 
> Yes, the values returned by move_pages() will not change.
> 
> The 'stats' in the kernel which are changing are user visible.  Specifically.
> the fields pgmigrate_success and pgmigrate_fail in the file /proc/vmstat.
> The values reported there for migrated hugetlb pages is changing as a result
> of this series.
> 
> In addition, if someone monitors the trace point at the end of migrate_pages
> they will start seeing different values.

Right, agree.

> 
> As mentioned, these values are not currently documented for hugetlb pages so
> I think it is OK to change.  If someone thinks otherwise, please speak up!
> 
> Making them be similar to what is reported for THP pages would be a good
> thing.

OK.

>>>
>>> Perhaps we should go ahead and document the hugetlb behavior when making these
>>> changes?
>>
>> Sure. How about adding below modification for hugetlb?
> 
> Yes, please do make the below changes as well.

Thanks.

Andrew, I am not sure you can help to fold below changes into your mm 
branch, or you want me to resend this patch set with adding below 
changes, or just send an incremental patch to add hugetlb documentation?

diff --git a/Documentation/vm/page_migration.rst
b/Documentation/vm/page_migration.rst
index 08810f5..8c5cb81 100644
--- a/Documentation/vm/page_migration.rst
+++ b/Documentation/vm/page_migration.rst
@@ -263,15 +263,15 @@ Monitoring Migration
   The following events (counters) can be used to monitor page migration.

   1. PGMIGRATE_SUCCESS: Normal page migration success. Each count means
that a
-   page was migrated. If the page was a non-THP page, then this counter is
-   increased by one. If the page was a THP, then this counter is
increased by
-   the number of THP subpages. For example, migration of a single 2MB
THP that
-   has 4KB-size base pages (subpages) will cause this counter to
increase by
-   512.
+   page was migrated. If the page was a non-THP and non-hugetlb page, then
+   this counter is increased by one. If the page was a THP or hugetlb, then
+   this counter is increased by the number of THP or hugetlb subpages.
+   For example, migration of a single 2MB THP that has 4KB-size base pages
+   (subpages) will cause this counter to increase by 512.

   2. PGMIGRATE_FAIL: Normal page migration failure. Same counting rules
as for
      PGMIGRATE_SUCCESS, above: this will be increased by the number of
subpages,
-   if it was a THP.
+   if it was a THP or hugetlb.


  reply	other threads:[~2021-11-25  5:50 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
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 [this message]
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=141bdfc6-f898-3cc3-f692-726c5f6cb74d@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=mike.kravetz@oracle.com \
    --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