[PATCH] x86: keep the page count correct

[PATCH] x86: keep the page count correct

[Yinghai Lu]

impact: get correct page count for 2M and 1G...

found page count in /proc/meminfo is nor correct on 1G system in VirtualBox 2.0.4

# cat /proc/meminfo
MemTotal:        1017508 kB
MemFree:          822700 kB
Buffers:            1456 kB
Cached:            26632 kB
SwapCached:            0 kB
...
Hugepagesize:       2048 kB
DirectMap4k:      4032 kB
DirectMap2M:  18446744073709549568 kB

with this patch get:
...
DirectMap4k:      4032 kB
DirectMap2M:   1044480 kB

which is consistent to kernel_page_tables
---[ Low Kernel Mapping ]---
0xffff880000000000-0xffff880000001000           4K     RW     PCD     GLB x  pte
0xffff880000001000-0xffff88000009f000         632K     RW             GLB x  pte
0xffff88000009f000-0xffff8800000a0000           4K     RW     PCD     GLB x  pte
0xffff8800000a0000-0xffff880000200000        1408K     RW             GLB x  pte
0xffff880000200000-0xffff88003fe00000        1020M     RW         PSE GLB x  pmd
0xffff88003fe00000-0xffff88003fff0000        1984K     RW             GLB NX pte
0xffff88003fff0000-0xffff880040000000          64K                           pte
0xffff880040000000-0xffff888000000000         511G                           pud
0xffff888000000000-0xffffc20000000000       58880G                           pgd

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 7df1209..701675a 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -350,8 +350,10 @@ phys_pte_init(pte_t *pte_page, unsigned long addr, unsigned long end,
 		 * pagetable pages as RO. So assume someone who pre-setup
 		 * these mappings are more intelligent.
 		 */
-		if (pte_val(*pte))
+		if (pte_val(*pte)) {
+			pages++;
 			continue;
+		}
 
 		if (0)
 			printk("   pte=%p addr=%lx pte=%016lx\n",
@@ -418,8 +420,10 @@ phys_pmd_init(pmd_t *pmd_page, unsigned long address, unsigned long end,
 			 * not differ with respect to page frame and
 			 * attributes.
 			 */
-			if (page_size_mask & (1 << PG_LEVEL_2M))
+			if (page_size_mask & (1 << PG_LEVEL_2M)) {
+				pages++;
 				continue;
+			}
 			new_prot = pte_pgprot(pte_clrhuge(*(pte_t *)pmd));
 		}
 
@@ -499,8 +503,10 @@ phys_pud_init(pud_t *pud_page, unsigned long addr, unsigned long end,
 			 * not differ with respect to page frame and
 			 * attributes.
 			 */
-			if (page_size_mask & (1 << PG_LEVEL_1G))
+			if (page_size_mask & (1 << PG_LEVEL_1G)) {
+				pages++;
 				continue;
+			}
 			prot = pte_pgprot(pte_clrhuge(*(pte_t *)pud));
 		}
 

Re: [PATCH] x86: keep the page count correct

[Suresh Siddha]

On Sat, Oct 25, 2008 at 10:58:21PM -0700, Yinghai Lu wrote:
> 
> impact: get correct page count for 2M and 1G...
> 
> found page count in /proc/meminfo is nor correct on 1G system in VirtualBox 2.0.4
> 
> # cat /proc/meminfo
> MemTotal:        1017508 kB
> MemFree:          822700 kB
> Buffers:            1456 kB
> Cached:            26632 kB
> SwapCached:            0 kB
> ...
> Hugepagesize:       2048 kB
> DirectMap4k:      4032 kB
> DirectMap2M:  18446744073709549568 kB
> 
> with this patch get:
> ...
> DirectMap4k:      4032 kB
> DirectMap2M:   1044480 kB
> 
> which is consistent to kernel_page_tables
> ---[ Low Kernel Mapping ]---
> 0xffff880000000000-0xffff880000001000           4K     RW     PCD     GLB x  pte
> 0xffff880000001000-0xffff88000009f000         632K     RW             GLB x  pte
> 0xffff88000009f000-0xffff8800000a0000           4K     RW     PCD     GLB x  pte
> 0xffff8800000a0000-0xffff880000200000        1408K     RW             GLB x  pte
> 0xffff880000200000-0xffff88003fe00000        1020M     RW         PSE GLB x  pmd
> 0xffff88003fe00000-0xffff88003fff0000        1984K     RW             GLB NX pte
> 0xffff88003fff0000-0xffff880040000000          64K                           pte
> 0xffff880040000000-0xffff888000000000         511G                           pud
> 0xffff888000000000-0xffffc20000000000       58880G                           pgd
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>

Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>

Re: [PATCH] x86: keep the page count correct

[Ingo Molnar]

* Suresh Siddha <suresh.b.siddha@intel.com> wrote:

> On Sat, Oct 25, 2008 at 10:58:21PM -0700, Yinghai Lu wrote:
> > 
> > impact: get correct page count for 2M and 1G...
> > 
> > found page count in /proc/meminfo is nor correct on 1G system in VirtualBox 2.0.4
> > 
> > # cat /proc/meminfo
> > MemTotal:        1017508 kB
> > MemFree:          822700 kB
> > Buffers:            1456 kB
> > Cached:            26632 kB
> > SwapCached:            0 kB
> > ...
> > Hugepagesize:       2048 kB
> > DirectMap4k:      4032 kB
> > DirectMap2M:  18446744073709549568 kB
> > 
> > with this patch get:
> > ...
> > DirectMap4k:      4032 kB
> > DirectMap2M:   1044480 kB
> > 
> > which is consistent to kernel_page_tables
> > ---[ Low Kernel Mapping ]---
> > 0xffff880000000000-0xffff880000001000           4K     RW     PCD     GLB x  pte
> > 0xffff880000001000-0xffff88000009f000         632K     RW             GLB x  pte
> > 0xffff88000009f000-0xffff8800000a0000           4K     RW     PCD     GLB x  pte
> > 0xffff8800000a0000-0xffff880000200000        1408K     RW             GLB x  pte
> > 0xffff880000200000-0xffff88003fe00000        1020M     RW         PSE GLB x  pmd
> > 0xffff88003fe00000-0xffff88003fff0000        1984K     RW             GLB NX pte
> > 0xffff88003fff0000-0xffff880040000000          64K                           pte
> > 0xffff880040000000-0xffff888000000000         511G                           pud
> > 0xffff888000000000-0xffffc20000000000       58880G                           pgd
> > 
> > Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> 
> Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>

applied to tip/x86/urgent, thanks guys!

	Ingo

[PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000)

[Yinghai Lu]

Impact: fix range calculation

when gart aperture is 0xdc000000 - 0xe0000000
it returned 0xc0000000 - 0xe0000000

PCI-DMA: Disabling AGP.
PCI-DMA: aperture base @ dc000000 size 65536 KB
init_memory_mapping
 00c0000000 - 00e0000000 page 2M
last_map_addr: e0000000 end: e0000000
PCI-DMA: using GART IOMMU.
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture

that is not right.

this patch fix that will get exact mapping

on 256g sytem with that aperture after patch
LBSuse:~ # cat /proc/meminfo
MemTotal:       264742432 kB
MemFree:        263920628 kB
Buffers:            1416 kB
Cached:            24468 kB
...
DirectMap4k:      5760 kB
DirectMap2M:   3205120 kB
DirectMap1G:  265289728 kB

it is consistent to
LBSuse:~ # cat /sys/kernel/debug/kernel_page_tables
..
---[ Low Kernel Mapping ]---
0xffff880000000000-0xffff880000200000           2M     RW             GLB x  pte
0xffff880000200000-0xffff880040000000        1022M     RW         PSE GLB x  pmd
0xffff880040000000-0xffff8800c0000000           2G     RW         PSE GLB NX pud
0xffff8800c0000000-0xffff8800d7e00000         382M     RW         PSE GLB NX pmd
0xffff8800d7e00000-0xffff8800d7fa0000        1664K     RW             GLB NX pte
0xffff8800d7fa0000-0xffff8800d8000000         384K                           pte
0xffff8800d8000000-0xffff8800dc000000          64M                           pmd
0xffff8800dc000000-0xffff8800e0000000          64M     RW         PSE GLB NX pmd
0xffff8800e0000000-0xffff880100000000         512M                           pmd
0xffff880100000000-0xffff880800000000          28G     RW         PSE GLB NX pud
0xffff880800000000-0xffff880824600000         582M     RW         PSE GLB NX pmd
0xffff880824600000-0xffff8808247f0000        1984K     RW             GLB NX pte
0xffff8808247f0000-0xffff880824800000          64K     RW     PCD     GLB NX pte
0xffff880824800000-0xffff880840000000         440M     RW         PSE GLB NX pmd
0xffff880840000000-0xffff884000000000         223G     RW         PSE GLB NX pud
0xffff884000000000-0xffff884028000000         640M     RW         PSE GLB NX pmd
0xffff884028000000-0xffff884040000000         384M                           pmd
0xffff884040000000-0xffff888000000000         255G                           pud
0xffff888000000000-0xffffc20000000000       58880G                           pgd 

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/mm/init_64.c |   26 +++++++++++++++-----------
 1 file changed, 15 insertions(+), 11 deletions(-)

Index: linux-2.6/arch/x86/mm/init_64.c
===================================================================
--- linux-2.6.orig/arch/x86/mm/init_64.c
+++ linux-2.6/arch/x86/mm/init_64.c
@@ -676,7 +676,7 @@ unsigned long __init_refok init_memory_m
 	int nr_range, i;
 	int use_pse, use_gbpages;
 
-	printk(KERN_INFO "init_memory_mapping\n");
+	printk(KERN_INFO "init_memory_mapping: %016lx-%016lx\n", start, end);
 
 	/*
 	 * Find space for the kernel direct mapping tables.
@@ -719,26 +719,30 @@ unsigned long __init_refok init_memory_m
 			 << (PMD_SHIFT - PAGE_SHIFT);
 	end_pfn = ((start + (PUD_SIZE - 1))>>PUD_SHIFT)
 			 << (PUD_SHIFT - PAGE_SHIFT);
-	if (end_pfn > ((end>>PUD_SHIFT)<<(PUD_SHIFT - PAGE_SHIFT)))
-		end_pfn = ((end>>PUD_SHIFT)<<(PUD_SHIFT - PAGE_SHIFT));
+	if (end_pfn > ((end>>PMD_SHIFT)<<(PMD_SHIFT - PAGE_SHIFT)))
+		end_pfn = ((end>>PMD_SHIFT)<<(PMD_SHIFT - PAGE_SHIFT));
 	nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
 			page_size_mask & (1<<PG_LEVEL_2M));
 
 	/* big page (1G) range */
-	start_pfn = end_pfn;
+	start_pfn = ((start + (PUD_SIZE - 1))>>PUD_SHIFT)
+			 << (PUD_SHIFT - PAGE_SHIFT);
 	end_pfn = (end>>PUD_SHIFT) << (PUD_SHIFT - PAGE_SHIFT);
-	nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
+	if (start_pfn < end_pfn) {
+		/* if no 1g blocks, no 2M blocks on tail*/
+		nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
 				page_size_mask &
 				 ((1<<PG_LEVEL_2M)|(1<<PG_LEVEL_1G)));
 
-	/* tail is not big page (1G) alignment */
-	start_pfn = end_pfn;
-	end_pfn = (end>>PMD_SHIFT) << (PMD_SHIFT - PAGE_SHIFT);
-	nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
-			page_size_mask & (1<<PG_LEVEL_2M));
+		/* tail is not big page (1G) alignment */
+		start_pfn = end_pfn;
+		end_pfn = (end>>PMD_SHIFT) << (PMD_SHIFT - PAGE_SHIFT);
+		nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
+				page_size_mask & (1<<PG_LEVEL_2M));
+	}
 
 	/* tail is not big page (2M) alignment */
-	start_pfn = end_pfn;
+	start_pfn = ((end>>PMD_SHIFT)<<(PMD_SHIFT - PAGE_SHIFT));
 	end_pfn = end>>PAGE_SHIFT;
 	nr_range = save_mr(mr, nr_range, start_pfn, end_pfn, 0);
 

Re: [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000)

[Ingo Molnar]

* Yinghai Lu <yinghai@kernel.org> wrote:

> Impact: fix range calculation

applied to tip/x86/urgent, thanks Yinghai!

i changed the impact line to:

Impact: change over-mapping to precise mapping, fix /proc/meminfo output

	Ingo

Re: [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000)

[Cyrill Gorcunov]

[Ingo Molnar - Tue, Oct 28, 2008 at 10:27:37AM +0100]
| 
| * Yinghai Lu <yinghai@kernel.org> wrote:
| 
| > Impact: fix range calculation
| 
| applied to tip/x86/urgent, thanks Yinghai!
| 
| i changed the impact line to:
| 
| Impact: change over-mapping to precise mapping, fix /proc/meminfo output
| 
| 	Ingo
| 

When we started to use Impact: line? I mean -- now we have
to use it? Just noticed this word in patches a day or maybe
several day ago -- so it seem to be quite freshy :)

		- Cyrill -

Re: [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000)

[Ingo Molnar]

* Cyrill Gorcunov <gorcunov@gmail.com> wrote:

> [Ingo Molnar - Tue, Oct 28, 2008 at 10:27:37AM +0100]
> | 
> | * Yinghai Lu <yinghai@kernel.org> wrote:
> | 
> | > Impact: fix range calculation
> | 
> | applied to tip/x86/urgent, thanks Yinghai!
> | 
> | i changed the impact line to:
> | 
> | Impact: change over-mapping to precise mapping, fix /proc/meminfo output
> | 
> | 	Ingo
> | 
> 
> When we started to use Impact: line? I mean -- now we have
> to use it? Just noticed this word in patches a day or maybe
> several day ago -- so it seem to be quite freshy :)

We've been experimenting with the impact-line for a couple of 
weeks/months, just to see how it works out in practice.

The first impact-line ever was added by hpa in mid-summer:

| commit 908ec7afacfdc83dc10938ed1d3c38b3526034ec
| Author: H. Peter Anvin <hpa@zytor.com>
| Date:   Mon Jun 30 14:42:18 2008 -0700
|
|    x86: remove arbitrary ELF section limit in i386 relocatable kernel
|    
|    Impact: build failure in maximal configurations

The concept seems to be quite good in general:

 - increases the readability of the changlogs

 - makes it easier to judge the backporting needs of a commit, even 
   if a commit has not been marked as Cc: <stable@kernel.org> straight 
   away.

 - makes it easier to notice bugs in a commit: when a commit marked as 
   "Impact: cleanup" causes some behavioral change it's clear that 
   it's buggy.

It basically acts as a second-level subject line.

So, given these many advantages, we now try to extend the use of 
impact-lines to all the tip/*/urgent branches.

It's not a must-have item for patch submissions, just a nice-to-have 
property. (we'll add the impact-line when it's missing)

	Ingo

Re: [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000)

[Cyrill Gorcunov]

[Ingo Molnar - Tue, Oct 28, 2008 at 07:10:04PM +0100]
| 
| * Cyrill Gorcunov <gorcunov@gmail.com> wrote:
| 
| > [Ingo Molnar - Tue, Oct 28, 2008 at 10:27:37AM +0100]
| > | 
| > | * Yinghai Lu <yinghai@kernel.org> wrote:
| > | 
| > | > Impact: fix range calculation
| > | 
| > | applied to tip/x86/urgent, thanks Yinghai!
| > | 
| > | i changed the impact line to:
| > | 
| > | Impact: change over-mapping to precise mapping, fix /proc/meminfo output
| > | 
| > | 	Ingo
| > | 
| > 
| > When we started to use Impact: line? I mean -- now we have
| > to use it? Just noticed this word in patches a day or maybe
| > several day ago -- so it seem to be quite freshy :)
| 
| We've been experimenting with the impact-line for a couple of 
| weeks/months, just to see how it works out in practice.
| 
| The first impact-line ever was added by hpa in mid-summer:
| 
| | commit 908ec7afacfdc83dc10938ed1d3c38b3526034ec
| | Author: H. Peter Anvin <hpa@zytor.com>
| | Date:   Mon Jun 30 14:42:18 2008 -0700
| |
| |    x86: remove arbitrary ELF section limit in i386 relocatable kernel
| |    
| |    Impact: build failure in maximal configurations
| 
| The concept seems to be quite good in general:
| 
|  - increases the readability of the changlogs
| 
|  - makes it easier to judge the backporting needs of a commit, even 
|    if a commit has not been marked as Cc: <stable@kernel.org> straight 
|    away.
| 
|  - makes it easier to notice bugs in a commit: when a commit marked as 
|    "Impact: cleanup" causes some behavioral change it's clear that 
|    it's buggy.
| 
| It basically acts as a second-level subject line.
| 
| So, given these many advantages, we now try to extend the use of 
| impact-lines to all the tip/*/urgent branches.
| 
| It's not a must-have item for patch submissions, just a nice-to-have 
| property. (we'll add the impact-line when it's missing)
| 
| 	Ingo
| 

Ingo, I think it's a subject for SubmittingPatches then. To
eliminate future possible questions for those who never saw it
before. Thanks for explanation!

		- Cyrill -

Re: [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000)

[Ingo Molnar]

* Cyrill Gorcunov <gorcunov@gmail.com> wrote:

> [Ingo Molnar - Tue, Oct 28, 2008 at 07:10:04PM +0100]
> | 
> | * Cyrill Gorcunov <gorcunov@gmail.com> wrote:
> | 
> | > [Ingo Molnar - Tue, Oct 28, 2008 at 10:27:37AM +0100]
> | > | 
> | > | * Yinghai Lu <yinghai@kernel.org> wrote:
> | > | 
> | > | > Impact: fix range calculation
> | > | 
> | > | applied to tip/x86/urgent, thanks Yinghai!
> | > | 
> | > | i changed the impact line to:
> | > | 
> | > | Impact: change over-mapping to precise mapping, fix /proc/meminfo output
> | > | 
> | > | 	Ingo
> | > | 
> | > 
> | > When we started to use Impact: line? I mean -- now we have
> | > to use it? Just noticed this word in patches a day or maybe
> | > several day ago -- so it seem to be quite freshy :)
> | 
> | We've been experimenting with the impact-line for a couple of 
> | weeks/months, just to see how it works out in practice.
> | 
> | The first impact-line ever was added by hpa in mid-summer:
> | 
> | | commit 908ec7afacfdc83dc10938ed1d3c38b3526034ec
> | | Author: H. Peter Anvin <hpa@zytor.com>
> | | Date:   Mon Jun 30 14:42:18 2008 -0700
> | |
> | |    x86: remove arbitrary ELF section limit in i386 relocatable kernel
> | |    
> | |    Impact: build failure in maximal configurations
> | 
> | The concept seems to be quite good in general:
> | 
> |  - increases the readability of the changlogs
> | 
> |  - makes it easier to judge the backporting needs of a commit, even 
> |    if a commit has not been marked as Cc: <stable@kernel.org> straight 
> |    away.
> | 
> |  - makes it easier to notice bugs in a commit: when a commit marked as 
> |    "Impact: cleanup" causes some behavioral change it's clear that 
> |    it's buggy.
> | 
> | It basically acts as a second-level subject line.
> | 
> | So, given these many advantages, we now try to extend the use of 
> | impact-lines to all the tip/*/urgent branches.
> | 
> | It's not a must-have item for patch submissions, just a nice-to-have 
> | property. (we'll add the impact-line when it's missing)
> | 
> | 	Ingo
> | 
> 
> Ingo, I think it's a subject for SubmittingPatches then. To 
> eliminate future possible questions for those who never saw it 
> before. Thanks for explanation!

well, this isnt an official policy in any way and we dont want to 
burden/complicate the life of other maintainers by putting it into 
linux/Documentation/SubmittingPatches. We are still experimenting with 
this concept - and while the results are very encouraging, YMMV!

	Ingo

Re: [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000)

[Cyrill Gorcunov]

[Ingo Molnar - Tue, Oct 28, 2008 at 07:18:00PM +0100]
...
| > 
| > Ingo, I think it's a subject for SubmittingPatches then. To 
| > eliminate future possible questions for those who never saw it 
| > before. Thanks for explanation!
| 
| well, this isnt an official policy in any way and we dont want to 
| burden/complicate the life of other maintainers by putting it into 
| linux/Documentation/SubmittingPatches. We are still experimenting with 
| this concept - and while the results are very encouraging, YMMV!
| 
| 	Ingo
| 

Got it, thanks!

		- Cyrill -

[PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) - v2

[Yinghai Lu]

Impact: change over-mapping to precise mapping, fix /proc/meminfo output

v2: fix less 1G ram system handling

when gart aperture is 0xdc000000 - 0xe0000000
it return 0xc0000000 - 0xe0000000

that is not right.

this patch fix that will get exact mapping

on 256g sytem with that aperture after patch
LBSuse:~ # cat /proc/meminfo
MemTotal:       264742432 kB
MemFree:        263920628 kB
Buffers:            1416 kB
Cached:            24468 kB
...
DirectMap4k:      5760 kB
DirectMap2M:   3205120 kB
DirectMap1G:  265289728 kB

it is consistent to
LBSuse:~ # cat /sys/kernel/debug/kernel_page_tables
..
---[ Low Kernel Mapping ]---
0xffff880000000000-0xffff880000200000           2M     RW             GLB x  pte
0xffff880000200000-0xffff880040000000        1022M     RW         PSE GLB x  pmd
0xffff880040000000-0xffff8800c0000000           2G     RW         PSE GLB NX pud
0xffff8800c0000000-0xffff8800d7e00000         382M     RW         PSE GLB NX pmd
0xffff8800d7e00000-0xffff8800d7fa0000        1664K     RW             GLB NX pte
0xffff8800d7fa0000-0xffff8800d8000000         384K                           pte
0xffff8800d8000000-0xffff8800dc000000          64M                           pmd
0xffff8800dc000000-0xffff8800e0000000          64M     RW         PSE GLB NX pmd
0xffff8800e0000000-0xffff880100000000         512M                           pmd
0xffff880100000000-0xffff880800000000          28G     RW         PSE GLB NX pud
0xffff880800000000-0xffff880824600000         582M     RW         PSE GLB NX pmd
0xffff880824600000-0xffff8808247f0000        1984K     RW             GLB NX pte
0xffff8808247f0000-0xffff880824800000          64K     RW     PCD     GLB NX pte
0xffff880824800000-0xffff880840000000         440M     RW         PSE GLB NX pmd
0xffff880840000000-0xffff884000000000         223G     RW         PSE GLB NX pud
0xffff884000000000-0xffff884028000000         640M     RW         PSE GLB NX pmd
0xffff884028000000-0xffff884040000000         384M                           pmd
0xffff884040000000-0xffff888000000000         255G                           pud
0xffff888000000000-0xffffc20000000000       58880G                           pgd 

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/mm/init_64.c |   50 +++++++++++++++++++++++++++++++++-----------------
 1 file changed, 33 insertions(+), 17 deletions(-)

Index: linux-2.6/arch/x86/mm/init_64.c
===================================================================
--- linux-2.6.orig/arch/x86/mm/init_64.c
+++ linux-2.6/arch/x86/mm/init_64.c
@@ -671,12 +671,13 @@ unsigned long __init_refok init_memory_m
 	unsigned long last_map_addr = 0;
 	unsigned long page_size_mask = 0;
 	unsigned long start_pfn, end_pfn;
+	unsigned long pos;
 
 	struct map_range mr[NR_RANGE_MR];
 	int nr_range, i;
 	int use_pse, use_gbpages;
 
-	printk(KERN_INFO "init_memory_mapping\n");
+	printk(KERN_INFO "init_memory_mapping: %016lx-%016lx\n", start, end);
 
 	/*
 	 * Find space for the kernel direct mapping tables.
@@ -710,35 +711,50 @@ unsigned long __init_refok init_memory_m
 
 	/* head if not big page alignment ?*/
 	start_pfn = start >> PAGE_SHIFT;
-	end_pfn = ((start + (PMD_SIZE - 1)) >> PMD_SHIFT)
+	pos = start_pfn << PAGE_SHIFT;
+	end_pfn = ((pos + (PMD_SIZE - 1)) >> PMD_SHIFT)
 			<< (PMD_SHIFT - PAGE_SHIFT);
-	nr_range = save_mr(mr, nr_range, start_pfn, end_pfn, 0);
+	if (start_pfn < end_pfn) {
+		nr_range = save_mr(mr, nr_range, start_pfn, end_pfn, 0);
+		pos = end_pfn << PAGE_SHIFT;
+	}
 
 	/* big page (2M) range*/
-	start_pfn = ((start + (PMD_SIZE - 1))>>PMD_SHIFT)
+	start_pfn = ((pos + (PMD_SIZE - 1))>>PMD_SHIFT)
 			 << (PMD_SHIFT - PAGE_SHIFT);
-	end_pfn = ((start + (PUD_SIZE - 1))>>PUD_SHIFT)
+	end_pfn = ((pos + (PUD_SIZE - 1))>>PUD_SHIFT)
 			 << (PUD_SHIFT - PAGE_SHIFT);
-	if (end_pfn > ((end>>PUD_SHIFT)<<(PUD_SHIFT - PAGE_SHIFT)))
-		end_pfn = ((end>>PUD_SHIFT)<<(PUD_SHIFT - PAGE_SHIFT));
-	nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
-			page_size_mask & (1<<PG_LEVEL_2M));
+	if (end_pfn > ((end>>PMD_SHIFT)<<(PMD_SHIFT - PAGE_SHIFT)))
+		end_pfn = ((end>>PMD_SHIFT)<<(PMD_SHIFT - PAGE_SHIFT));
+	if (start_pfn < end_pfn) {
+		nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
+				page_size_mask & (1<<PG_LEVEL_2M));
+		pos = end_pfn << PAGE_SHIFT;
+	}
 
 	/* big page (1G) range */
-	start_pfn = end_pfn;
-	end_pfn = (end>>PUD_SHIFT) << (PUD_SHIFT - PAGE_SHIFT);
-	nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
+	start_pfn = ((pos + (PUD_SIZE - 1))>>PUD_SHIFT)
+			 << (PUD_SHIFT - PAGE_SHIFT);
+	end_pfn = (end >> PUD_SHIFT) << (PUD_SHIFT - PAGE_SHIFT);
+	if (start_pfn < end_pfn) {
+		nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
 				page_size_mask &
 				 ((1<<PG_LEVEL_2M)|(1<<PG_LEVEL_1G)));
+		pos = end_pfn << PAGE_SHIFT;
+	}
 
 	/* tail is not big page (1G) alignment */
-	start_pfn = end_pfn;
-	end_pfn = (end>>PMD_SHIFT) << (PMD_SHIFT - PAGE_SHIFT);
-	nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
-			page_size_mask & (1<<PG_LEVEL_2M));
+	start_pfn = ((pos + (PMD_SIZE - 1))>>PMD_SHIFT)
+			 << (PMD_SHIFT - PAGE_SHIFT);
+	end_pfn = (end >> PMD_SHIFT) << (PMD_SHIFT - PAGE_SHIFT);
+	if (start_pfn < end_pfn) {
+		nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
+				page_size_mask & (1<<PG_LEVEL_2M));
+		pos = end_pfn << PAGE_SHIFT;
+	}
 
 	/* tail is not big page (2M) alignment */
-	start_pfn = end_pfn;
+	start_pfn = pos>>PAGE_SHIFT;
 	end_pfn = end>>PAGE_SHIFT;
 	nr_range = save_mr(mr, nr_range, start_pfn, end_pfn, 0);
 

Re: [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) - v2

[Ingo Molnar]

* Yinghai Lu <yinghai@kernel.org> wrote:

> Impact: change over-mapping to precise mapping, fix /proc/meminfo 
> output
> 
> v2: fix less 1G ram system handling

applied to tip/x86/urgent, thanks Yinghai!

	Ingo