* [PATCH] x86: keep the page count correct @ 2008-10-26 5:58 Yinghai Lu 2008-10-27 16:50 ` Suresh Siddha 0 siblings, 1 reply; 12+ messages in thread From: Yinghai Lu @ 2008-10-26 5:58 UTC (permalink / raw) To: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Suresh Siddha, Jeremy Fitzhardinge, Andrew Morton Cc: linux-kernel 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)); } ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] x86: keep the page count correct 2008-10-26 5:58 [PATCH] x86: keep the page count correct Yinghai Lu @ 2008-10-27 16:50 ` Suresh Siddha 2008-10-27 17:55 ` Ingo Molnar 0 siblings, 1 reply; 12+ messages in thread From: Suresh Siddha @ 2008-10-27 16:50 UTC (permalink / raw) To: Yinghai Lu Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Siddha, Suresh B, Jeremy Fitzhardinge, Andrew Morton, linux-kernel 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86: keep the page count correct 2008-10-27 16:50 ` Suresh Siddha @ 2008-10-27 17:55 ` Ingo Molnar 2008-10-28 1:52 ` [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) Yinghai Lu 0 siblings, 1 reply; 12+ messages in thread From: Ingo Molnar @ 2008-10-27 17:55 UTC (permalink / raw) To: Suresh Siddha Cc: Yinghai Lu, Thomas Gleixner, H. Peter Anvin, Jeremy Fitzhardinge, Andrew Morton, linux-kernel * 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) 2008-10-27 17:55 ` Ingo Molnar @ 2008-10-28 1:52 ` Yinghai Lu 2008-10-28 9:27 ` Ingo Molnar 0 siblings, 1 reply; 12+ messages in thread From: Yinghai Lu @ 2008-10-28 1:52 UTC (permalink / raw) To: Ingo Molnar, Suresh Siddha, Thomas Gleixner, H. Peter Anvin, Jeremy Fitzhardinge, Andrew Morton Cc: linux-kernel 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); ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) 2008-10-28 1:52 ` [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) Yinghai Lu @ 2008-10-28 9:27 ` Ingo Molnar 2008-10-28 17:48 ` Cyrill Gorcunov [not found] ` <20081028093930.GA9699@elte.hu> 0 siblings, 2 replies; 12+ messages in thread From: Ingo Molnar @ 2008-10-28 9:27 UTC (permalink / raw) To: Yinghai Lu Cc: Suresh Siddha, Thomas Gleixner, H. Peter Anvin, Jeremy Fitzhardinge, Andrew Morton, linux-kernel * 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) 2008-10-28 9:27 ` Ingo Molnar @ 2008-10-28 17:48 ` Cyrill Gorcunov 2008-10-28 18:10 ` Ingo Molnar [not found] ` <20081028093930.GA9699@elte.hu> 1 sibling, 1 reply; 12+ messages in thread From: Cyrill Gorcunov @ 2008-10-28 17:48 UTC (permalink / raw) To: Ingo Molnar Cc: Yinghai Lu, Suresh Siddha, Thomas Gleixner, H. Peter Anvin, Jeremy Fitzhardinge, Andrew Morton, linux-kernel [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 - ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) 2008-10-28 17:48 ` Cyrill Gorcunov @ 2008-10-28 18:10 ` Ingo Molnar 2008-10-28 18:14 ` Cyrill Gorcunov 0 siblings, 1 reply; 12+ messages in thread From: Ingo Molnar @ 2008-10-28 18:10 UTC (permalink / raw) To: Cyrill Gorcunov Cc: Yinghai Lu, Suresh Siddha, Thomas Gleixner, H. Peter Anvin, Jeremy Fitzhardinge, Andrew Morton, linux-kernel * 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) 2008-10-28 18:10 ` Ingo Molnar @ 2008-10-28 18:14 ` Cyrill Gorcunov 2008-10-28 18:18 ` Ingo Molnar 0 siblings, 1 reply; 12+ messages in thread From: Cyrill Gorcunov @ 2008-10-28 18:14 UTC (permalink / raw) To: Ingo Molnar Cc: Yinghai Lu, Suresh Siddha, Thomas Gleixner, H. Peter Anvin, Jeremy Fitzhardinge, Andrew Morton, linux-kernel [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 - ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) 2008-10-28 18:14 ` Cyrill Gorcunov @ 2008-10-28 18:18 ` Ingo Molnar 2008-10-28 18:22 ` Cyrill Gorcunov 0 siblings, 1 reply; 12+ messages in thread From: Ingo Molnar @ 2008-10-28 18:18 UTC (permalink / raw) To: Cyrill Gorcunov Cc: Yinghai Lu, Suresh Siddha, Thomas Gleixner, H. Peter Anvin, Jeremy Fitzhardinge, Andrew Morton, linux-kernel * 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) 2008-10-28 18:18 ` Ingo Molnar @ 2008-10-28 18:22 ` Cyrill Gorcunov 0 siblings, 0 replies; 12+ messages in thread From: Cyrill Gorcunov @ 2008-10-28 18:22 UTC (permalink / raw) To: Ingo Molnar Cc: Yinghai Lu, Suresh Siddha, Thomas Gleixner, H. Peter Anvin, Jeremy Fitzhardinge, Andrew Morton, linux-kernel [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 - ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <20081028093930.GA9699@elte.hu>]
[parent not found: <20081028094758.GA11958@elte.hu>]
[parent not found: <4906E048.6060006@kernel.org>]
[parent not found: <20081028095244.GY15734@elte.hu>]
* [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) - v2 [not found] ` <20081028095244.GY15734@elte.hu> @ 2008-10-28 19:39 ` Yinghai Lu 2008-10-28 19:55 ` Ingo Molnar 0 siblings, 1 reply; 12+ messages in thread From: Yinghai Lu @ 2008-10-28 19:39 UTC (permalink / raw) To: Ingo Molnar, Suresh Siddha, Thomas Gleixner, H. Peter Anvin, Andrew Morton Cc: linux-kernel 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); ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) - v2 2008-10-28 19:39 ` [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) - v2 Yinghai Lu @ 2008-10-28 19:55 ` Ingo Molnar 0 siblings, 0 replies; 12+ messages in thread From: Ingo Molnar @ 2008-10-28 19:55 UTC (permalink / raw) To: Yinghai Lu Cc: Suresh Siddha, Thomas Gleixner, H. Peter Anvin, Andrew Morton, linux-kernel * 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2008-10-28 19:55 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-26 5:58 [PATCH] x86: keep the page count correct Yinghai Lu
2008-10-27 16:50 ` Suresh Siddha
2008-10-27 17:55 ` Ingo Molnar
2008-10-28 1:52 ` [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) Yinghai Lu
2008-10-28 9:27 ` Ingo Molnar
2008-10-28 17:48 ` Cyrill Gorcunov
2008-10-28 18:10 ` Ingo Molnar
2008-10-28 18:14 ` Cyrill Gorcunov
2008-10-28 18:18 ` Ingo Molnar
2008-10-28 18:22 ` Cyrill Gorcunov
[not found] ` <20081028093930.GA9699@elte.hu>
[not found] ` <20081028094758.GA11958@elte.hu>
[not found] ` <4906E048.6060006@kernel.org>
[not found] ` <20081028095244.GY15734@elte.hu>
2008-10-28 19:39 ` [PATCH] x86: fix init_memory_mapping for [dc000000 - e0000000) - v2 Yinghai Lu
2008-10-28 19:55 ` Ingo Molnar
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).