[PATCH] x86: keep the page count correct - Kernel

This is a discussion on [PATCH] x86: keep the page count correct - 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 ...

+ Reply to Thread
Results 1 to 12 of 12

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

  1. [PATCH] x86: keep the page count correct


    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

    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));
    }

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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


    Acked-by: Suresh Siddha
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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


    * Suresh Siddha 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

    >
    > Acked-by: Suresh Siddha


    applied to tip/x86/urgent, thanks guys!

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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


    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

    ---
    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<
    /* 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<
    - /* 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< + /* 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< + }

    /* 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);

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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


    * Yinghai Lu 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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    [Ingo Molnar - Tue, Oct 28, 2008 at 10:27:37AM +0100]
    |
    | * Yinghai Lu 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 -
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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


    * Cyrill Gorcunov wrote:

    > [Ingo Molnar - Tue, Oct 28, 2008 at 07:10:04PM +0100]
    > |
    > | * Cyrill Gorcunov wrote:
    > |
    > | > [Ingo Molnar - Tue, Oct 28, 2008 at 10:27:37AM +0100]
    > | > |
    > | > | * Yinghai Lu 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
    > | | 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: 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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    [Ingo Molnar - Tue, Oct 28, 2008 at 07:10:04PM +0100]
    |
    | * Cyrill Gorcunov wrote:
    |
    | > [Ingo Molnar - Tue, Oct 28, 2008 at 10:27:37AM +0100]
    | > |
    | > | * Yinghai Lu 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
    | | 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: 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 -
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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


    * Cyrill Gorcunov wrote:

    > [Ingo Molnar - Tue, Oct 28, 2008 at 10:27:37AM +0100]
    > |
    > | * Yinghai Lu 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
    | 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: 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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    [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 -
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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


    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

    ---
    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< + 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< + 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< + 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< + 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< + 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);


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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


    * Yinghai Lu 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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread