archive mirror
 help / color / mirror / Atom feed
From: Anshuman Khandual <>
To: Michal Hocko <>
Cc:, Daniel Jordan <>,
	Zi Yan <>, John Hubbard <>,
	Mike Kravetz <>,
	Oscar Salvador <>,
	Andrew Morton <>,
Subject: Re: [RFC V2] mm/vmstat: Add events for HugeTLB migration
Date: Mon, 5 Oct 2020 07:59:12 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 10/02/2020 05:34 PM, Michal Hocko wrote:
> On Wed 30-09-20 11:30:49, Anshuman Khandual wrote:
>> Add following new vmstat events which will track HugeTLB page migration.
>> It follows the existing semantics to accommodate HugeTLB subpages in total
>> page migration statistics. While here, this updates current trace event
>> 'mm_migrate_pages' to accommodate now available HugeTLB based statistics.
> What is the actual usecase? And how do you deal with the complexity
> introduced by many different hugetlb page sizes. Really, what is the
> point to having such a detailed view on hugetlb migration?

It helps differentiate various page migration events i.e normal, THP and
HugeTLB and gives us more reliable and accurate measurement. Current stats
as per PGMIGRATE_SUCCESS and PGMIGRATE_FAIL are misleading, as they contain
both normal and HugeTLB pages as single entities, which is not accurate.

After this change, PGMIGRATE_SUCCESS and PGMIGRATE_FAIL will contain page
migration statistics in terms of normal pages irrespective of whether any
previous migrations until that point involved normal pages, THP or HugeTLB
(any size) pages. At the least, this fixes existing misleading stats with

Besides, it helps us understand HugeTLB migrations in more detail. Even
though HugeTLB can be of various sizes on a given platform, these new
overall insight into HugeTLB migration events.

Though these new stats accumulate HugeTLB migration success and failure
irrespective of their size, it will still be helpful as HugeTLB is user
driven, who should be able to decipher these accumulated stats. But this
is a limitation, as it might be difficult to determine available HugeTLB
sizes at compile time.

  reply	other threads:[~2020-10-05  2:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30  6:00 [RFC V2] mm/vmstat: Add events for HugeTLB migration Anshuman Khandual
2020-09-30  7:46 ` Oscar Salvador
2020-09-30 10:02   ` Anshuman Khandual
2020-09-30 10:33     ` Oscar Salvador
2020-10-01 22:16 ` Mike Kravetz
2020-10-02 12:04 ` Michal Hocko
2020-10-05  2:29   ` Anshuman Khandual [this message]
2020-10-05  6:05     ` Michal Hocko
2020-10-06  2:56       ` Anshuman Khandual
2020-10-06  7:54         ` Michal Hocko

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).