From: "Zi Yan" <zi.yan@sent.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: "kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"minchan@kernel.org" <minchan@kernel.org>,
"vbabka@suse.cz" <vbabka@suse.cz>,
"mgorman@techsingularity.net" <mgorman@techsingularity.net>,
"mhocko@kernel.org" <mhocko@kernel.org>,
"khandual@linux.vnet.ibm.com" <khandual@linux.vnet.ibm.com>,
"dnellans@nvidia.com" <dnellans@nvidia.com>,
"dave.hansen@intel.com" <dave.hansen@intel.com>
Subject: Re: [PATCH v8 06/10] mm: thp: check pmd migration entry in common path
Date: Fri, 14 Jul 2017 14:29:07 -0400 [thread overview]
Message-ID: <3144A36B-4C90-4BEF-B4A7-3658D37DE618@sent.com> (raw)
In-Reply-To: <20170714092943.GA14125@hori1.linux.bs1.fc.nec.co.jp>
[-- Attachment #1: Type: text/plain, Size: 3790 bytes --]
On 14 Jul 2017, at 5:29, Naoya Horiguchi wrote:
> On Sat, Jul 01, 2017 at 09:40:04AM -0400, Zi Yan wrote:
>> From: Zi Yan <zi.yan@cs.rutgers.edu>
>>
>> If one of callers of page migration starts to handle thp,
>> memory management code start to see pmd migration entry, so we need
>> to prepare for it before enabling. This patch changes various code
>> point which checks the status of given pmds in order to prevent race
>> between thp migration and the pmd-related works.
>>
>> ChangeLog v1 -> v2:
>> - introduce pmd_related() (I know the naming is not good, but can't
>> think up no better name. Any suggesntion is welcomed.)
>>
>> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>>
>> ChangeLog v2 -> v3:
>> - add is_swap_pmd()
>> - a pmd entry should be pmd pointing to pte pages, is_swap_pmd(),
>> pmd_trans_huge(), pmd_devmap(), or pmd_none()
>> - pmd_none_or_trans_huge_or_clear_bad() and pmd_trans_unstable() return
>> true on pmd_migration_entry, so that migration entries are not
>> treated as pmd page table entries.
>>
>> ChangeLog v4 -> v5:
>> - add explanation in pmd_none_or_trans_huge_or_clear_bad() to state
>> the equivalence of !pmd_present() and is_pmd_migration_entry()
>> - fix migration entry wait deadlock code (from v1) in follow_page_mask()
>> - remove unnecessary code (from v1) in follow_trans_huge_pmd()
>> - use is_swap_pmd() instead of !pmd_present() for pmd migration entry,
>> so it will not be confused with pmd_none()
>> - change author information
>>
>> ChangeLog v5 -> v7
>> - use macro to disable the code when thp migration is not enabled
>>
>> ChangeLog v7 -> v8
>> - remove not used code in do_huge_pmd_wp_page()
>> - copy the comment from change_pte_range() on downgrading
>> write migration entry to read to change_huge_pmd()
>>
>> Signed-off-by: Zi Yan <zi.yan@cs.rutgers.edu>
>> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>> ---
>> arch/x86/mm/gup.c | 7 +++--
>> fs/proc/task_mmu.c | 33 ++++++++++++++-------
>> include/asm-generic/pgtable.h | 17 ++++++++++-
>> include/linux/huge_mm.h | 14 +++++++--
>> mm/gup.c | 22 ++++++++++++--
>> mm/huge_memory.c | 67 +++++++++++++++++++++++++++++++++++++++----
>> mm/memcontrol.c | 5 ++++
>> mm/memory.c | 12 ++++++--
>> mm/mprotect.c | 4 +--
>> mm/mremap.c | 2 +-
>> 10 files changed, 154 insertions(+), 29 deletions(-)
>>
>> diff --git a/arch/x86/mm/gup.c b/arch/x86/mm/gup.c
>> index 456dfdfd2249..096bbcc801e6 100644
>> --- a/arch/x86/mm/gup.c
>> +++ b/arch/x86/mm/gup.c
>> @@ -9,6 +9,7 @@
>> #include <linux/vmstat.h>
>> #include <linux/highmem.h>
>> #include <linux/swap.h>
>> +#include <linux/swapops.h>
>> #include <linux/memremap.h>
>>
>> #include <asm/mmu_context.h>
>> @@ -243,9 +244,11 @@ static int gup_pmd_range(pud_t pud, unsigned long addr, unsigned long end,
>> pmd_t pmd = *pmdp;
>>
>> next = pmd_addr_end(addr, end);
>> - if (pmd_none(pmd))
>> + if (!pmd_present(pmd)) {
>> + VM_BUG_ON(is_swap_pmd(pmd) && IS_ENABLED(CONFIG_MIGRATION) &&
>> + !is_pmd_migration_entry(pmd));
>
> This VM_BUG_ON() triggers when gup is called on hugetlb hwpoison entry.
> I think that in such case kernel falls into the gup slow path, and
> a page fault in follow_hugetlb_page() can properly report the error to
> affected processes, so no need to alarm with BUG_ON.
>
> Could you make this VM_BUG_ON more specific, or just remove it?
I will remove it, since adding code to detect hugetlb hwpoison entry
to existing VM_BUG_ON() will be quite messy.
Thanks for pointing this out.
--
Best Regards
Yan Zi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 496 bytes --]
next prev parent reply other threads:[~2017-07-14 18:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-01 13:39 [PATCH v8 00/10] mm: page migration enhancement for thp Zi Yan
2017-07-01 13:39 ` [PATCH v8 01/10] mm: mempolicy: add queue_pages_required() Zi Yan
2017-07-01 13:40 ` [PATCH v8 02/10] mm: x86: move _PAGE_SWP_SOFT_DIRTY from bit 7 to bit 1 Zi Yan
2017-07-01 13:40 ` [PATCH v8 03/10] mm: thp: introduce separate TTU flag for thp freezing Zi Yan
2017-07-01 13:40 ` [PATCH v8 04/10] mm: thp: introduce CONFIG_ARCH_ENABLE_THP_MIGRATION Zi Yan
2017-07-01 13:40 ` [PATCH v8 05/10] mm: thp: enable thp migration in generic path Zi Yan
2017-07-02 17:57 ` Kirill A. Shutemov
2017-07-03 1:26 ` Zi Yan
2017-07-11 6:47 ` Naoya Horiguchi
2017-07-11 14:00 ` Zi Yan
2017-07-13 9:30 ` Naoya Horiguchi
2017-07-13 11:28 ` Zi Yan
2017-07-14 0:06 ` Naoya Horiguchi
2017-07-01 13:40 ` [PATCH v8 06/10] mm: thp: check pmd migration entry in common path Zi Yan
2017-07-14 9:29 ` Naoya Horiguchi
2017-07-14 18:29 ` Zi Yan [this message]
2017-07-01 13:40 ` [PATCH v8 07/10] mm: soft-dirty: keep soft-dirty bits over thp migration Zi Yan
2017-07-01 13:40 ` [PATCH v8 08/10] mm: mempolicy: mbind and migrate_pages support " Zi Yan
2017-07-01 13:40 ` [PATCH v8 09/10] mm: migrate: move_pages() supports " Zi Yan
2017-07-01 13:40 ` [PATCH v8 10/10] mm: memory_hotplug: memory hotremove " 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=3144A36B-4C90-4BEF-B4A7-3658D37DE618@sent.com \
--to=zi.yan@sent.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=dnellans@nvidia.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=minchan@kernel.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=vbabka@suse.cz \
/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).