All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Tatashin <pasha.tatashin@soleen.com>
To: pasha.tatashin@soleen.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, akpm@linux-foundation.org, vbabka@suse.cz,
	mhocko@suse.com, david@redhat.com, osalvador@suse.de,
	dan.j.williams@intel.com, sashal@kernel.org,
	tyhicks@linux.microsoft.com, iamjoonsoo.kim@lge.com,
	mike.kravetz@oracle.com, rostedt@goodmis.org, mingo@redhat.com,
	jgg@ziepe.ca, peterz@infradead.org, mgorman@suse.de,
	willy@infradead.org, rientjes@google.com, jhubbard@nvidia.com,
	linux-doc@vger.kernel.org, ira.weiny@intel.com,
	linux-kselftest@vger.kernel.org, jmorris@namei.org
Subject: [PATCH v11 08/14] mm/gup: do not migrate zero page
Date: Mon, 15 Feb 2021 11:13:43 -0500	[thread overview]
Message-ID: <20210215161349.246722-9-pasha.tatashin@soleen.com> (raw)
In-Reply-To: <20210215161349.246722-1-pasha.tatashin@soleen.com>

On some platforms ZERO_PAGE(0) might end-up in a movable zone. Do not
migrate zero page in gup during longterm pinning as migration of zero page
is not allowed.

For example, in x86 QEMU with 16G of memory and kernelcore=5G parameter, I
see the following:

Boot#1: zero_pfn  0x48a8d zero_pfn zone: ZONE_DMA32
Boot#2: zero_pfn 0x20168d zero_pfn zone: ZONE_MOVABLE

On x86, empty_zero_page is declared in .bss and depending on the loader
may end up in different physical locations during boots.

Also, move is_zero_pfn() my_zero_pfn() functions under CONFIG_MMU, because
zero_pfn that they are using is declared in memory.c which is compiled
with CONFIG_MMU.

Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
---
 include/linux/mm.h      |  3 ++-
 include/linux/mmzone.h  |  4 ++++
 include/linux/pgtable.h | 12 ++++++++++++
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 7f56d8d62148..3c75df55ed00 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1496,7 +1496,8 @@ static inline unsigned long page_to_section(const struct page *page)
 #ifdef CONFIG_MIGRATION
 static inline bool is_pinnable_page(struct page *page)
 {
-	return !is_zone_movable_page(page) && !is_migrate_cma_page(page);
+	return !(is_zone_movable_page(page) || is_migrate_cma_page(page)) ||
+		is_zero_pfn(page_to_pfn(page));
 }
 #else
 static inline bool is_pinnable_page(struct page *page)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index b593316bff3d..c56f508be031 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -407,6 +407,10 @@ enum zone_type {
 	 *    techniques might use alloc_contig_range() to hide previously
 	 *    exposed pages from the buddy again (e.g., to implement some sort
 	 *    of memory unplug in virtio-mem).
+	 * 6. ZERO_PAGE(0), kernelcore/movablecore setups might create
+	 *    situations where ZERO_PAGE(0) which is allocated differently
+	 *    on different platforms may end up in a movable zone. ZERO_PAGE(0)
+	 *    cannot be migrated.
 	 *
 	 * In general, no unmovable allocations that degrade memory offlining
 	 * should end up in ZONE_MOVABLE. Allocators (like alloc_contig_range())
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 8fcdfa52eb4b..7c6cba3d80f0 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -1115,6 +1115,7 @@ extern void untrack_pfn(struct vm_area_struct *vma, unsigned long pfn,
 extern void untrack_pfn_moved(struct vm_area_struct *vma);
 #endif
 
+#ifdef CONFIG_MMU
 #ifdef __HAVE_COLOR_ZERO_PAGE
 static inline int is_zero_pfn(unsigned long pfn)
 {
@@ -1138,6 +1139,17 @@ static inline unsigned long my_zero_pfn(unsigned long addr)
 	return zero_pfn;
 }
 #endif
+#else
+static inline int is_zero_pfn(unsigned long pfn)
+{
+	return 0;
+}
+
+static inline unsigned long my_zero_pfn(unsigned long addr)
+{
+	return 0;
+}
+#endif /* CONFIG_MMU */
 
 #ifdef CONFIG_MMU
 
-- 
2.25.1


  parent reply	other threads:[~2021-02-15 17:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-15 16:13 [PATCH v11 00/14] prohibit pinning pages in ZONE_MOVABLE Pavel Tatashin
2021-02-15 16:13 ` [PATCH v11 01/14] mm/gup: don't pin migrated cma pages in movable zone Pavel Tatashin
2021-02-15 16:13 ` [PATCH v11 02/14] mm/gup: check every subpage of a compound page during isolation Pavel Tatashin
2021-02-15 16:13 ` [PATCH v11 03/14] mm/gup: return an error on migration failure Pavel Tatashin
2021-02-15 16:13 ` [PATCH v11 04/14] mm/gup: check for isolation errors Pavel Tatashin
2021-02-15 16:13 ` [PATCH v11 05/14] mm cma: rename PF_MEMALLOC_NOCMA to PF_MEMALLOC_PIN Pavel Tatashin
2021-02-15 16:13 ` [PATCH v11 06/14] mm: apply per-task gfp constraints in fast path Pavel Tatashin
2021-02-15 16:13 ` [PATCH v11 07/14] mm: honor PF_MEMALLOC_PIN for all movable pages Pavel Tatashin
2021-02-15 16:13 ` Pavel Tatashin [this message]
2021-02-15 16:13 ` [PATCH v11 09/14] mm/gup: migrate pinned pages out of movable zone Pavel Tatashin
2021-02-15 16:13 ` [PATCH v11 10/14] memory-hotplug.rst: add a note about ZONE_MOVABLE and page pinning Pavel Tatashin
2021-02-15 16:13 ` [PATCH v11 11/14] mm/gup: change index type to long as it counts pages Pavel Tatashin
2021-02-15 16:13 ` [PATCH v11 12/14] mm/gup: longterm pin migration cleanup Pavel Tatashin
2021-02-15 16:13 ` [PATCH v11 13/14] selftests/vm: gup_test: fix test flag Pavel Tatashin
2021-02-15 16:13 ` [PATCH v11 14/14] selftests/vm: gup_test: test faulting in kernel, and verify pinnable pages Pavel Tatashin

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=20210215161349.246722-9-pasha.tatashin@soleen.com \
    --to=pasha.tatashin@soleen.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=ira.weiny@intel.com \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=jmorris@namei.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=mingo@redhat.com \
    --cc=osalvador@suse.de \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=rostedt@goodmis.org \
    --cc=sashal@kernel.org \
    --cc=tyhicks@linux.microsoft.com \
    --cc=vbabka@suse.cz \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.