lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 24 Nov 2021 11:05:09 -0800
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Baolin Wang <baolin.wang@...ux.alibaba.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     ziy@...dia.com, shy828301@...il.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] mm: migrate: Correct the hugetlb migration stats

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@...ux.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.

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.

>>
>> 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.
-- 
Mike Kravetz

> 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.
> 
>  3. THP_MIGRATION_SUCCESS: A THP was migrated without being split.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ