linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Zi Yan <ziy@nvidia.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>,
	<linux-mm@kvack.org>, <hughd@google.com>,
	<daniel.m.jordan@oracle.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	John Hubbard <jhubbard@nvidia.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2] mm/vmstat: Add events for THP migration without split
Date: Thu, 4 Jun 2020 12:49:11 -0400	[thread overview]
Message-ID: <2735DD7E-0DBF-428B-AAD8-FC6DAAA9CB1E@nvidia.com> (raw)
In-Reply-To: <20200604163657.GV19604@bombadil.infradead.org>

[-- Attachment #1: Type: text/plain, Size: 4021 bytes --]

On 4 Jun 2020, at 12:36, Matthew Wilcox wrote:

> On Thu, Jun 04, 2020 at 09:51:10AM -0400, Zi Yan wrote:
>> On 4 Jun 2020, at 7:34, Matthew Wilcox wrote:
>>> On Thu, Jun 04, 2020 at 09:30:45AM +0530, Anshuman Khandual wrote:
>>>> +Quantifying Migration
>>>> +=====================
>>>> +Following events can be used to quantify page migration.
>>>> +
>>>> +- PGMIGRATE_SUCCESS
>>>> +- PGMIGRATE_FAIL
>>>> +- THP_MIGRATION_SUCCESS
>>>> +- THP_MIGRATION_FAILURE
>>>> +
>>>> +THP_MIGRATION_FAILURE in particular represents an event when a THP could not be
>>>> +migrated as a single entity following an allocation failure and ended up getting
>>>> +split into constituent normal pages before being retried. This event, along with
>>>> +PGMIGRATE_SUCCESS and PGMIGRATE_FAIL will help in quantifying and analyzing THP
>>>> +migration events including both success and failure cases.
>>>
>>> First, I'd suggest running this paragraph through 'fmt'.  That way you
>>> don't have to care about line lengths.
>>>
>>> Second, this paragraph doesn't really explain what I need to know to
>>> understand the meaning of these numbers.  When Linux attempts to migrate
>>> a THP, one of three things can happen:
>>>
>>>  - It is migrated as a single THP
>>>  - It is migrated, but had to be split
>>>  - Migration fails
>>>
>>> How do I turn these four numbers into an understanding of how often each
>>> of those three situations happen?  And why do we need four numbers to
>>> report three situations?
>>>
>>> Or is there something else that can happen?  If so, I'd like that explained
>>> here too ;-)
>>
>> PGMIGRATE_SUCCESS and PGMIGRATE_FAIL record a combination of different events,
>> so it is not easy to interpret them. Let me try to explain them.
>
> Thanks!  Very helpful explanation.
>
>> 1. migrating only base pages: PGMIGRATE_SUCCESS and PGMIGRATE_FAIL just mean
>> these base pages are migrated and fail to migrate respectively.
>> THP_MIGRATION_SUCCESS and THP_MIGRATION_FAILURE should be 0 in this case.
>> Simple.
>>
>> 2. migrating only THPs:
>> 	- PGMIGRATE_SUCCESS means THPs that are migrated and base pages
>> 	(from the split of THPs) that are migrated,
>>
>> 	- PGMIGRATE_FAIL means THPs that fail to migrate and base pages that fail to migrated.
>>
>> 	- THP_MIGRATION_SUCCESS means THPs that are migrated.
>>
>> 	- THP_MIGRATION_FAILURE means THPs that are split.
>>
>> So PGMIGRATE_SUCCESS - THP_MIGRATION_SUCCESS means the number of migrated base pages,
>> which are from the split of THPs.
>
> Are you sure about that?  If I split a THP and each of those subpages
> migrates, won't I then see PGMIGRATE_SUCCESS increase by 512?

That is what I mean. I guess my words did not work. I should have used subpages.

>
>> When it comes to analyze failed migration, PGMIGRATE_FAIL - THP_MIGRATION_FAILURE
>> means the number of pages that are failed to migrate, but we cannot tell how many
>> are base pages and how many are THPs.
>>
>> 3. migrating base pages and THP:
>>
>> The math should be very similar to the second case, except that
>> a) from PGMIGRATE_SUCCESS - THP_MIGRATION_SUCCESS, we cannot tell how many are pages begin
>> as base pages and how many are pages begin as THPs but become base pages after split;
>> b) from PGMIGRATE_FAIL - THP_MIGRATION_FAILURE, an additional case,
>> base pages that begin as base pages fail to migrate, is mixed into the number and we
>> cannot tell three cases apart.
>
> So why don't we just expose PGMIGRATE_SPLIT?  That would be defined as
> the number of times we succeeded in migrating a THP but had to split it
> to succeed.

It might need extra code to get that number. Currently, the subpages from split
THPs are appended to the end of the original page list, so we might need a separate
page list for these subpages to count PGMIGRATE_SPLIT. Also what if some of the
subpages fail to migrate? Do we increase PGMIGRATE_SPLIT or not?



--
Best Regards,
Yan Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]

  reply	other threads:[~2020-06-04 16:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-04  4:00 [PATCH V2] mm/vmstat: Add events for THP migration without split Anshuman Khandual
2020-06-04 11:34 ` Matthew Wilcox
2020-06-04 13:51   ` Zi Yan
2020-06-04 16:36     ` Matthew Wilcox
2020-06-04 16:49       ` Zi Yan [this message]
2020-06-05  3:35         ` Anshuman Khandual
2020-06-05 14:24           ` Zi Yan
2020-06-09 11:35             ` Anshuman Khandual
2020-06-09 22:29               ` Daniel Jordan
2020-06-09 23:06               ` Zi Yan

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=2735DD7E-0DBF-428B-AAD8-FC6DAAA9CB1E@nvidia.com \
    --to=ziy@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=daniel.m.jordan@oracle.com \
    --cc=hughd@google.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=willy@infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).