From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Oscar Salvador <osalvador@suse.de>
Cc: linux-mm@kvack.org, Daniel Jordan <daniel.m.jordan@oracle.com>,
Zi Yan <ziy@nvidia.com>, John Hubbard <jhubbard@nvidia.com>,
Mike Kravetz <mike.kravetz@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] mm/vmstat: Add events for HugeTLB migration
Date: Mon, 28 Sep 2020 09:02:23 +0530 [thread overview]
Message-ID: <c1ea761e-087d-645b-6c1a-ff2a930ab400@arm.com> (raw)
In-Reply-To: <20200925094912.GA31664@linux>
On 09/25/2020 03:19 PM, Oscar Salvador wrote:
> On Fri, Sep 25, 2020 at 02:42:29PM +0530, Anshuman Khandual wrote:
>> Add following new vmstat events which will track HugeTLB page migration.
>>
>> 1. HUGETLB_MIGRATION_SUCCESS
>> 2. HUGETLB_MIGRATION_FAILURE
>>
>> 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.
>>
>> Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
>> Cc: Zi Yan <ziy@nvidia.com>
>> Cc: John Hubbard <jhubbard@nvidia.com>
>> Cc: Mike Kravetz <mike.kravetz@oracle.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>
> Was this inspired by some usecase/debugging or just to follow THP's example?
Currently HugeTLB migration events get accommodated in PGMIGRATE_SUCCESS and
PGMIGRATE_FAIL event stats as normal single page instances. Previously this
might have just seemed okay as HugeTLB page could be viewed as a single page
entity, even though it was not fully accurate as PGMIGRATE_[SUCCESS|FAILURE]
tracked statistics in terms of normal base pages.
But tracking HugeTLB pages as single pages does not make sense any more, now
that THP pages are accounted for properly. This would complete the revamped
page migration accounting where PGMIGRATE_[SUCCESS|FAILURE] will track entire
page migration events in terms of normal base pages and THP_*/HUGETLB_* will
track specialized events when applicable.
>
>> int retry = 1;
>> int thp_retry = 1;
>> + int hugetlb_retry = 1;
>> int nr_failed = 0;
>> int nr_succeeded = 0;
>> int nr_thp_succeeded = 0;
>> int nr_thp_failed = 0;
>> int nr_thp_split = 0;
>> + int nr_hugetlb_succeeded = 0;
>> + int nr_hugetlb_failed = 0;
>> int pass = 0;
>> bool is_thp = false;
>> + bool is_hugetlb = false;
>> struct page *page;
>> struct page *page2;
>> int swapwrite = current->flags & PF_SWAPWRITE;
>> @@ -1433,6 +1437,7 @@ int migrate_pages(struct list_head *from, new_page_t get_new_page,
>> for (pass = 0; pass < 10 && (retry || thp_retry); pass++) {
>
> Should you not have put hugetlb_retry within the loop as well?
> Otherwise we might not rety for hugetlb pages now?
>
Right, will fix it.
next prev parent reply other threads:[~2020-09-28 3:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-25 9:12 Anshuman Khandual
2020-09-25 9:49 ` Oscar Salvador
2020-09-28 3:32 ` Anshuman Khandual [this message]
2020-09-28 22:04 ` Mike Kravetz
2020-09-29 6:02 ` Anshuman Khandual
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=c1ea761e-087d-645b-6c1a-ff2a930ab400@arm.com \
--to=anshuman.khandual@arm.com \
--cc=akpm@linux-foundation.org \
--cc=daniel.m.jordan@oracle.com \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=osalvador@suse.de \
--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