linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Wei Yang <richardw.yang@linux.intel.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Wei Yang <richardw.yang@linux.intel.com>,
	akpm@linux-foundation.org, kirill.shutemov@linux.intel.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	richard.weiyang@gmail.com
Subject: Re: [RFC PATCH] mm/rmap.c: finer hwpoison granularity for PTE-mapped THP
Date: Fri, 10 Jan 2020 09:55:48 +0800	[thread overview]
Message-ID: <20200110015548.GA16823@richard> (raw)
In-Reply-To: <20200109123233.ye2h4dxaubu4ad22@box>

On Thu, Jan 09, 2020 at 03:32:33PM +0300, Kirill A. Shutemov wrote:
>On Thu, Jan 02, 2020 at 11:04:21AM +0800, Wei Yang wrote:
>> Currently we behave differently between PMD-mapped THP and PTE-mapped
>> THP on memory_failure.
>> 
>> User detected difference:
>> 
>>     For PTE-mapped THP, the whole 2M range will trigger MCE after
>>     memory_failure(), while only 4K range for PMD-mapped THP will.
>> 
>> Direct reason:
>> 
>>     All the 512 PTE entry will be marked as hwpoison entry for a PTE-mapped
>>     THP while only one PTE will be marked for a PMD-mapped THP.
>> 
>> Root reason:
>> 
>>     The root cause is PTE-mapped page doesn't need to split pmd which skip
>>     the SPLIT_FREEZE process.
>
>I don't follow how SPLIT_FREEZE is related to pisoning. Cold you
>laraborate?
>

Sure. Let me try to explain this a little.

    split_huge_page_to_list
        unmap_page
	    try_to_unmap_one
                ...
                __split_huge_pmd_locked
        __split_huge_page
            remap_page

There are two dimensions:

   * PMD mapped THP and PTE mapped THP
   * HWPOISON-ed page and non-HWPOISON-ed page

So there are total 4 cases.

1. First let's take a look at the normal case, when HWPOISON is not set.

If the page is PMD-mapped, SPLIT_FREEZE is passed down in flags. And finally
passed to __split_huge_pmd_locked. In this function, when freeze is true, PTE
will be set to migration entry. And because __split_huge_pmd_locked save
migration entry to PTE, try_to_unmap_one will not do real unmap. Then
remap_page restore those migration entry back. 

If the page is PTE-mapped, __split_huge_pmd_locked will be skipped since this
is already done. This means try_to_unmap_one will do the real unmap. Because
SPLIT_FREEZE is passed, PTE will be set to migration entry, which is the same
behavior as PMD-mapped page. Then remap_page restore those migration entry
back.

This shows PMD-mapped and PTE-mapped page share the same result on split.

While difference is who sets PTE as migration entry

  * __split_huge_pmd_locked does this job for PMD-mapped page
  * try_to_unmap_one does this job for PTE-mapped page

2. Now let's take a look at the HWPOISON case.

There are two critical differences 

  * __split_huge_pmd_locked is skipped for PTE-mapped page
  * HWPOISON effects the behavior of try_to_unmap_one

Then for PMD-mapped page, HWPOISON has no effect on split. But for PTE-mapped
page, all PTE will be set to hwpoison entry.

Then in memory_failure, the page split will have two different PTE result.

Not sure I explain it clearly.

-- 
Wei Yang
Help you, Help me


      reply	other threads:[~2020-01-10  1:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-02  3:04 Wei Yang
2020-01-09 12:32 ` Kirill A. Shutemov
2020-01-10  1:55   ` Wei Yang [this message]

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=20200110015548.GA16823@richard \
    --to=richardw.yang@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=richard.weiyang@gmail.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