linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Greg Ungerer <gerg@linux-m68k.org>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Jonathan Corbet <corbet@lwn.net>,
	Matt Turner <mattst88@gmail.com>, Meelis Roos <mroos@linux.ee>,
	Michael Schmitz <schmitzmic@gmail.com>,
	Mike Rapoport <rppt@kernel.org>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Russell King <linux@armlinux.org.uk>,
	Tony Luck <tony.luck@intel.com>,
	Vineet Gupta <vgupta@synopsys.com>, Will Deacon <will@kernel.org>,
	linux-alpha@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
	linux-mm@kvack.org, linux-snps-arc@lists.infradead.org
Subject: [PATCH v2 06/13] ia64: forbid using VIRTUAL_MEM_MAP with FLATMEM
Date: Sun,  1 Nov 2020 19:04:47 +0200	[thread overview]
Message-ID: <20201101170454.9567-7-rppt@kernel.org> (raw)
In-Reply-To: <20201101170454.9567-1-rppt@kernel.org>

From: Mike Rapoport <rppt@linux.ibm.com>

Virtual memory map was intended to avoid wasting memory on the memory map
on systems with large holes in the physical memory layout. Long ago it been
superseded first by DISCONTIGMEM and then by SPARSEMEM. Moreover,
SPARSEMEM_VMEMMAP provide the same functionality in much more portable way.

As the first step to removing the VIRTUAL_MEM_MAP forbid it's usage with
FLATMEM and panic on systems with large holes in the physical memory
layout that try to run FLATMEM kernels.

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 arch/ia64/Kconfig               |  2 +-
 arch/ia64/include/asm/meminit.h |  2 --
 arch/ia64/mm/contig.c           | 48 +++++++++++++++------------------
 arch/ia64/mm/init.c             | 14 ----------
 4 files changed, 22 insertions(+), 44 deletions(-)

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 12aae706cb27..83de0273d474 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -329,7 +329,7 @@ config NODES_SHIFT
 # VIRTUAL_MEM_MAP has been retained for historical reasons.
 config VIRTUAL_MEM_MAP
 	bool "Virtual mem map"
-	depends on !SPARSEMEM
+	depends on !SPARSEMEM && !FLATMEM
 	default y
 	help
 	  Say Y to compile the kernel with support for a virtual mem map.
diff --git a/arch/ia64/include/asm/meminit.h b/arch/ia64/include/asm/meminit.h
index 092f1c91b36c..e789c0818edb 100644
--- a/arch/ia64/include/asm/meminit.h
+++ b/arch/ia64/include/asm/meminit.h
@@ -59,10 +59,8 @@ extern int reserve_elfcorehdr(u64 *start, u64 *end);
 extern int register_active_ranges(u64 start, u64 len, int nid);
 
 #ifdef CONFIG_VIRTUAL_MEM_MAP
-# define LARGE_GAP	0x40000000 /* Use virtual mem map if hole is > than this */
   extern unsigned long VMALLOC_END;
   extern struct page *vmem_map;
-  extern int find_largest_hole(u64 start, u64 end, void *arg);
   extern int create_mem_map_page_table(u64 start, u64 end, void *arg);
   extern int vmemmap_find_next_valid_pfn(int, int);
 #else
diff --git a/arch/ia64/mm/contig.c b/arch/ia64/mm/contig.c
index ba81d8cb0059..bfc4ecd0a2ab 100644
--- a/arch/ia64/mm/contig.c
+++ b/arch/ia64/mm/contig.c
@@ -19,15 +19,12 @@
 #include <linux/mm.h>
 #include <linux/nmi.h>
 #include <linux/swap.h>
+#include <linux/sizes.h>
 
 #include <asm/meminit.h>
 #include <asm/sections.h>
 #include <asm/mca.h>
 
-#ifdef CONFIG_VIRTUAL_MEM_MAP
-static unsigned long max_gap;
-#endif
-
 /* physical address where the bootmem map is located */
 unsigned long bootmap_start;
 
@@ -166,33 +163,30 @@ find_memory (void)
 	alloc_per_cpu_data();
 }
 
-static void __init virtual_map_init(void)
+static int __init find_largest_hole(u64 start, u64 end, void *arg)
 {
-#ifdef CONFIG_VIRTUAL_MEM_MAP
-	efi_memmap_walk(find_largest_hole, (u64 *)&max_gap);
-	if (max_gap < LARGE_GAP) {
-		vmem_map = (struct page *) 0;
-	} else {
-		unsigned long map_size;
+	u64 *max_gap = arg;
 
-		/* allocate virtual_mem_map */
+	static u64 last_end = PAGE_OFFSET;
 
-		map_size = PAGE_ALIGN(ALIGN(max_low_pfn, MAX_ORDER_NR_PAGES) *
-			sizeof(struct page));
-		VMALLOC_END -= map_size;
-		vmem_map = (struct page *) VMALLOC_END;
-		efi_memmap_walk(create_mem_map_page_table, NULL);
+	/* NOTE: this algorithm assumes efi memmap table is ordered */
 
-		/*
-		 * alloc_node_mem_map makes an adjustment for mem_map
-		 * which isn't compatible with vmem_map.
-		 */
-		NODE_DATA(0)->node_mem_map = vmem_map +
-			find_min_pfn_with_active_regions();
+	if (*max_gap < (start - last_end))
+		*max_gap = start - last_end;
+	last_end = end;
+	return 0;
+}
 
-		printk("Virtual mem_map starts at 0x%p\n", mem_map);
-	}
-#endif /* !CONFIG_VIRTUAL_MEM_MAP */
+static void __init verify_gap_absence(void)
+{
+	unsigned long max_gap;
+
+	/* Forbid FLATMEM if hole is > than 1G */
+	efi_memmap_walk(find_largest_hole, (u64 *)&max_gap);
+	if (max_gap >= SZ_1G)
+		panic("Cannot use FLATMEM with %ldMB hole\n"
+		      "Please switch over to SPARSEMEM\n",
+		      (max_gap >> 20));
 }
 
 /*
@@ -210,7 +204,7 @@ paging_init (void)
 	max_zone_pfns[ZONE_DMA32] = max_dma;
 	max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
 
-	virtual_map_init();
+	verify_gap_absence();
 
 	free_area_init(max_zone_pfns);
 	zero_page_memmap_ptr = virt_to_page(ia64_imva(empty_zero_page));
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index ef12e097f318..9b5acf8fb092 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -574,20 +574,6 @@ ia64_pfn_valid (unsigned long pfn)
 }
 EXPORT_SYMBOL(ia64_pfn_valid);
 
-int __init find_largest_hole(u64 start, u64 end, void *arg)
-{
-	u64 *max_gap = arg;
-
-	static u64 last_end = PAGE_OFFSET;
-
-	/* NOTE: this algorithm assumes efi memmap table is ordered */
-
-	if (*max_gap < (start - last_end))
-		*max_gap = start - last_end;
-	last_end = end;
-	return 0;
-}
-
 #endif /* CONFIG_VIRTUAL_MEM_MAP */
 
 int __init register_active_ranges(u64 start, u64 len, int nid)
-- 
2.28.0


  parent reply	other threads:[~2020-11-01 17:05 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-01 17:04 [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM Mike Rapoport
2020-11-01 17:04 ` [PATCH v2 01/13] alpha: switch from DISCONTIGMEM to SPARSEMEM Mike Rapoport
2020-11-01 17:04 ` [PATCH v2 02/13] ia64: remove custom __early_pfn_to_nid() Mike Rapoport
2020-11-01 17:04 ` [PATCH v2 03/13] ia64: remove 'ifdef CONFIG_ZONE_DMA32' statements Mike Rapoport
2020-11-01 17:04 ` [PATCH v2 04/13] ia64: discontig: paging_init(): remove local max_pfn calculation Mike Rapoport
2020-11-01 17:04 ` [PATCH v2 05/13] ia64: split virtual map initialization out of paging_init() Mike Rapoport
2020-11-01 17:04 ` Mike Rapoport [this message]
2020-11-01 17:04 ` [PATCH v2 07/13] ia64: make SPARSEMEM default and disable DISCONTIGMEM Mike Rapoport
2020-11-01 17:04 ` [PATCH v2 08/13] arm: remove CONFIG_ARCH_HAS_HOLES_MEMORYMODEL Mike Rapoport
2020-11-02  9:43   ` David Hildenbrand
2020-11-01 17:04 ` [PATCH v2 09/13] arm, arm64: move free_unused_memmap() to generic mm Mike Rapoport
2020-11-14 12:15   ` Catalin Marinas
2020-11-01 17:04 ` [PATCH v2 10/13] arc: use FLATMEM with freeing of unused memory map instead of DISCONTIGMEM Mike Rapoport
2020-11-17  6:40   ` Vineet Gupta
2020-11-17  6:57     ` Mike Rapoport
2020-11-01 17:04 ` [PATCH v2 11/13] m68k/mm: make node data and node setup depend on CONFIG_DISCONTIGMEM Mike Rapoport
2020-11-01 17:04 ` [PATCH v2 12/13] m68k/mm: enable use of generic memory_model.h for !DISCONTIGMEM Mike Rapoport
2020-11-01 17:04 ` [PATCH v2 13/13] m68k: deprecate DISCONTIGMEM Mike Rapoport
2020-11-17  5:24 ` [PATCH v2 00/13] arch, mm: " John Paul Adrian Glaubitz
2020-11-17  6:23   ` Mike Rapoport
2020-11-17  8:07     ` John Paul Adrian Glaubitz
2020-11-17  8:14       ` Mike Rapoport
2020-12-01  9:10     ` John Paul Adrian Glaubitz
2020-12-01 10:29       ` Mike Rapoport
2020-12-01 11:35         ` John Paul Adrian Glaubitz
2020-12-01 12:10           ` Mike Rapoport
2020-12-01 12:16             ` John Paul Adrian Glaubitz
2020-12-01 13:56               ` Mike Rapoport
2020-12-01 15:03                 ` Jens Axboe
2020-12-01 15:33                   ` Geert Uytterhoeven
2020-12-02  8:43                     ` Christoph Hellwig
2020-12-02  8:45                       ` John Paul Adrian Glaubitz
2020-12-02  8:46                         ` Christoph Hellwig
2020-12-02  8:46                       ` Mike Rapoport
2020-12-02  8:47                         ` Christoph Hellwig
2020-12-01 15:07                 ` John Paul Adrian Glaubitz
2020-12-01 19:55                   ` John Paul Adrian Glaubitz
2020-12-02  7:14                     ` Mike Rapoport

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=20201101170454.9567-7-rppt@kernel.org \
    --to=rppt@kernel.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=geert@linux-m68k.org \
    --cc=gerg@linux-m68k.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=mattst88@gmail.com \
    --cc=mroos@linux.ee \
    --cc=rppt@linux.ibm.com \
    --cc=schmitzmic@gmail.com \
    --cc=tony.luck@intel.com \
    --cc=vgupta@synopsys.com \
    --cc=will@kernel.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).