Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yinghai Lu <yinghai@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Tang Chen <tangchen@cn.fujitsu.com>,
	Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Subject: linux-next: manual merge of the akpm-current tree with the tip tree
Date: Wed, 30 Oct 2013 17:40:25 +1100
Message-ID: <20131030174025.0cd5d6ad218a1bea872646c2@canb.auug.org.au> (raw)

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
arch/x86/mm/init.c between commit 6979287a7df6 ("x86/mm: Add 'step_size'
comments to init_mem_mapping()") from the tip tree and commits
6452c268c6d6 ("x86/mm: factor out of top-down direct mapping setup") and
f790250c098a ("x86/mem-hotplug: support initialize page tables in
bottom-up") from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/mm/init.c
index ce32017c5e38,b6892a71cbfc..000000000000
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@@ -399,28 -399,23 +399,39 @@@ static unsigned long __init init_range_
  	return mapped_ram_size;
  }
  
 -/* (PUD_SHIFT-PMD_SHIFT)/2 */
 -#define STEP_SIZE_SHIFT 5
 +static unsigned long __init get_new_step_size(unsigned long step_size)
 +{
 +	/*
 +	 * Explain why we shift by 5 and why we don't have to worry about
 +	 * 'step_size << 5' overflowing:
 +	 *
 +	 * initial mapped size is PMD_SIZE (2M).
 +	 * We can not set step_size to be PUD_SIZE (1G) yet.
 +	 * In worse case, when we cross the 1G boundary, and
 +	 * PG_LEVEL_2M is not set, we will need 1+1+512 pages (2M + 8k)
 +	 * to map 1G range with PTE. Use 5 as shift for now.
 +	 *
 +	 * Don't need to worry about overflow, on 32bit, when step_size
 +	 * is 0, round_down() returns 0 for start, and that turns it
 +	 * into 0x100000000ULL.
 +	 */
 +	return step_size << 5;
 +}
  
- void __init init_mem_mapping(void)
+ /**
+  * memory_map_top_down - Map [map_start, map_end) top down
+  * @map_start: start address of the target memory range
+  * @map_end: end address of the target memory range
+  *
+  * This function will setup direct mapping for memory range
+  * [map_start, map_end) in top-down. That said, the page tables
+  * will be allocated at the end of the memory, and we map the
+  * memory in top-down.
+  */
+ static void __init memory_map_top_down(unsigned long map_start,
+ 				       unsigned long map_end)
  {
- 	unsigned long end, real_end, start, last_start;
+ 	unsigned long real_end, start, last_start;
  	unsigned long step_size;
  	unsigned long addr;
  	unsigned long mapped_ram_size = 0;
@@@ -470,8 -454,89 +470,89 @@@
  		mapped_ram_size += new_mapped_ram_size;
  	}
  
- 	if (real_end < end)
- 		init_range_memory_mapping(real_end, end);
+ 	if (real_end < map_end)
+ 		init_range_memory_mapping(real_end, map_end);
+ }
+ 
+ /**
+  * memory_map_bottom_up - Map [map_start, map_end) bottom up
+  * @map_start: start address of the target memory range
+  * @map_end: end address of the target memory range
+  *
+  * This function will setup direct mapping for memory range
+  * [map_start, map_end) in bottom-up. Since we have limited the
+  * bottom-up allocation above the kernel, the page tables will
+  * be allocated just above the kernel and we map the memory
+  * in [map_start, map_end) in bottom-up.
+  */
+ static void __init memory_map_bottom_up(unsigned long map_start,
+ 					unsigned long map_end)
+ {
+ 	unsigned long next, new_mapped_ram_size, start;
+ 	unsigned long mapped_ram_size = 0;
+ 	/* step_size need to be small so pgt_buf from BRK could cover it */
+ 	unsigned long step_size = PMD_SIZE;
+ 
+ 	start = map_start;
+ 	min_pfn_mapped = start >> PAGE_SHIFT;
+ 
+ 	/*
+ 	 * We start from the bottom (@map_start) and go to the top (@map_end).
+ 	 * The memblock_find_in_range() gets us a block of RAM from the
+ 	 * end of RAM in [min_pfn_mapped, max_pfn_mapped) used as new pages
+ 	 * for page table.
+ 	 */
+ 	while (start < map_end) {
+ 		if (map_end - start > step_size) {
+ 			next = round_up(start + 1, step_size);
+ 			if (next > map_end)
+ 				next = map_end;
+ 		} else
+ 			next = map_end;
+ 
+ 		new_mapped_ram_size = init_range_memory_mapping(start, next);
+ 		start = next;
+ 
+ 		if (new_mapped_ram_size > mapped_ram_size)
 -			step_size <<= STEP_SIZE_SHIFT;
++			step_size = get_new_step_size(step_size);
+ 		mapped_ram_size += new_mapped_ram_size;
+ 	}
+ }
+ 
+ void __init init_mem_mapping(void)
+ {
+ 	unsigned long end;
+ 
+ 	probe_page_size_mask();
+ 
+ #ifdef CONFIG_X86_64
+ 	end = max_pfn << PAGE_SHIFT;
+ #else
+ 	end = max_low_pfn << PAGE_SHIFT;
+ #endif
+ 
+ 	/* the ISA range is always mapped regardless of memory holes */
+ 	init_memory_mapping(0, ISA_END_ADDRESS);
+ 
+ 	/*
+ 	 * If the allocation is in bottom-up direction, we setup direct mapping
+ 	 * in bottom-up, otherwise we setup direct mapping in top-down.
+ 	 */
+ 	if (memblock_bottom_up()) {
+ 		unsigned long kernel_end = __pa_symbol(_end);
+ 
+ 		/*
+ 		 * we need two separate calls here. This is because we want to
+ 		 * allocate page tables above the kernel. So we first map
+ 		 * [kernel_end, end) to make memory above the kernel be mapped
+ 		 * as soon as possible. And then use page tables allocated above
+ 		 * the kernel to map [ISA_END_ADDRESS, kernel_end).
+ 		 */
+ 		memory_map_bottom_up(kernel_end, end);
+ 		memory_map_bottom_up(ISA_END_ADDRESS, kernel_end);
+ 	} else {
+ 		memory_map_top_down(ISA_END_ADDRESS, end);
+ 	}
  
  #ifdef CONFIG_X86_64
  	if (max_pfn > max_low_pfn) {

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

             reply index

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-30  6:40 Stephen Rothwell [this message]
2013-11-08  7:48 Stephen Rothwell
2013-11-08 18:58 ` Josh Triplett
2013-11-08 23:20   ` Stephen Rothwell
2013-11-09  0:19     ` Josh Triplett
2014-01-07  6:00 Stephen Rothwell
2014-01-07  6:34 ` Tang Chen
2014-01-14  4:53 Stephen Rothwell
2014-01-14  5:04 ` Davidlohr Bueso
2014-01-14 12:51 ` Peter Zijlstra
2014-01-14 13:17   ` Geert Uytterhoeven
2014-01-14 13:33     ` Peter Zijlstra
2014-01-14 16:19     ` H. Peter Anvin
2014-01-14 15:15   ` H. Peter Anvin
2014-01-14 15:20     ` Geert Uytterhoeven
2014-01-14 15:41       ` Peter Zijlstra
2014-01-14 15:48         ` H. Peter Anvin
2014-03-17  9:31 Stephen Rothwell
2014-03-17  9:36 ` Peter Zijlstra
2014-03-19 23:27   ` Andrew Morton
2015-04-08  8:25 Stephen Rothwell
2015-04-08  8:28 Stephen Rothwell
2015-06-04 12:07 Stephen Rothwell
2015-07-28  6:00 Stephen Rothwell
2015-07-29 17:12 ` Andrea Arcangeli
2015-07-29 17:47   ` Andy Lutomirski
2015-07-29 18:46     ` Thomas Gleixner
2015-07-30 15:38       ` Andrea Arcangeli
2015-07-29 23:06   ` Stephen Rothwell
2015-07-29 23:07     ` Thomas Gleixner
2015-09-07 23:35   ` Stephen Rothwell
2015-09-08 18:11     ` Linus Torvalds
2015-09-08 22:56       ` Stephen Rothwell
2015-09-08 23:03         ` Linus Torvalds
2015-09-08 23:21           ` Andrew Morton
2015-09-16  6:58             ` Geert Uytterhoeven
2015-10-02  4:21 Stephen Rothwell
2015-12-07  8:06 Stephen Rothwell
2016-02-19  4:09 Stephen Rothwell
2016-02-19 15:26 ` Ard Biesheuvel
2016-02-26  5:07 Stephen Rothwell
2016-02-26 21:35 ` Andrew Morton
2016-03-02  5:40 Stephen Rothwell
2016-04-29  6:12 Stephen Rothwell
2016-04-29  6:26 ` Ingo Molnar
2016-06-15  5:23 Stephen Rothwell
2016-06-18 19:39 ` Manfred Spraul
2016-07-29  4:14 Stephen Rothwell
2016-11-14  6:08 Stephen Rothwell
2017-02-17  4:40 Stephen Rothwell
2017-03-24  5:25 Stephen Rothwell
2017-04-12  6:46 Stephen Rothwell
2017-04-12 20:53 ` Vlastimil Babka
2017-04-20  2:17   ` NeilBrown
2017-08-11  7:53 Stephen Rothwell
2017-08-11  9:34 ` Peter Zijlstra
2017-08-11 10:48   ` Peter Zijlstra
2017-08-11 11:45   ` Stephen Rothwell
2017-08-11 11:56     ` Ingo Molnar
2017-08-11 12:17       ` Peter Zijlstra
2017-08-11 12:44         ` Ingo Molnar
2017-08-11 13:49           ` Stephen Rothwell
2017-08-11 14:04       ` Peter Zijlstra
2017-08-13  6:06         ` Nadav Amit
2017-08-13 12:50           ` Peter Zijlstra
2017-08-14  3:16             ` Minchan Kim
2017-08-14  5:07               ` Nadav Amit
2017-08-14  5:23                 ` Minchan Kim
2017-08-14  8:38                 ` Minchan Kim
2017-08-14 19:57                   ` Peter Zijlstra
2017-08-16  4:14                     ` Minchan Kim
2017-08-14 19:38                 ` Peter Zijlstra
2017-08-15  7:51                   ` Nadav Amit
2017-08-14  3:09         ` Minchan Kim
2017-08-14 18:54           ` Peter Zijlstra
2017-08-22  6:57 Stephen Rothwell
2017-08-23  6:39 ` Vlastimil Babka
2017-11-02  7:19 Stephen Rothwell
2017-11-10  4:33 Stephen Rothwell
2017-12-18  5:04 Stephen Rothwell
2018-03-23  5:59 Stephen Rothwell
2018-08-20  4:32 Stephen Rothwell
2018-08-20 19:52 ` Andrew Morton
2019-01-31  4:31 Stephen Rothwell
2019-05-01 11:10 Stephen Rothwell
2019-06-24 10:24 Stephen Rothwell
2019-10-31  5:43 Stephen Rothwell

Reply instructions:

You may reply publically 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=20131030174025.0cd5d6ad218a1bea872646c2@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=tangchen@cn.fujitsu.com \
    --cc=tglx@linutronix.de \
    --cc=yinghai@kernel.org \
    --cc=zhangyanfei@cn.fujitsu.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

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git