From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: fix init_memory_mapping over boundary v2
Date: Sat, 28 Jun 2008 10:38:04 -0700 [thread overview]
Message-ID: <486676FC.0@goop.org> (raw)
In-Reply-To: <200806272247.11971.yhlu.kernel@gmail.com>
Yinghai Lu wrote:
> some end boundary is only page alignment, instead of 2M alignment,
> so call ker_phycial_mapping_init three times.
> then don't overmap above the max_low_pfn
>
> v2: make init_memory_mapping more solid: start could be any value other than 0
>
> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
>
> ---
> arch/x86/mm/init_32.c | 86 ++++++++++++++++++++++++++++++++++++--------------
> 1 file changed, 62 insertions(+), 24 deletions(-)
>
> Index: linux-2.6/arch/x86/mm/init_32.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/mm/init_32.c
> +++ linux-2.6/arch/x86/mm/init_32.c
> @@ -184,8 +184,9 @@ static inline int is_kernel_text(unsigne
> * PAGE_OFFSET:
> */
> static void __init kernel_physical_mapping_init(pgd_t *pgd_base,
> - unsigned long start,
> - unsigned long end)
> + unsigned long start_pfn,
> + unsigned long end_pfn,
> + int use_pse)
>
Better to use bool for use_pse.
> {
> int pgd_idx, pmd_idx, pte_ofs;
> unsigned long pfn;
> @@ -193,32 +194,30 @@ static void __init kernel_physical_mappi
> pmd_t *pmd;
> pte_t *pte;
> unsigned pages_2m = 0, pages_4k = 0;
> - unsigned limit_pfn = end >> PAGE_SHIFT;
>
> - pgd_idx = pgd_index(PAGE_OFFSET);
> - pgd = pgd_base + pgd_idx;
> - pfn = start >> PAGE_SHIFT;
> + if (!cpu_has_pse)
> + use_pse = 0;
>
What are the semantics of the use_pse argument? Is it just a hint? If
so, then the caller below should just pass a constant 1/true.
>
> + pfn = start_pfn;
> + pgd_idx = pgd_index((pfn<<PAGE_SHIFT) + PAGE_OFFSET);
> + pgd = pgd_base + pgd_idx;
> for (; pgd_idx < PTRS_PER_PGD; pgd++, pgd_idx++) {
> pmd = one_md_table_init(pgd);
> - if (pfn >= limit_pfn)
> +
> + if (pfn >= end_pfn)
> continue;
>
> - for (pmd_idx = 0;
> - pmd_idx < PTRS_PER_PMD && pfn < limit_pfn;
> + pmd_idx = pmd_index((pfn<<PAGE_SHIFT) + PAGE_OFFSET);
> + pmd += pmd_idx;
> + for (; pmd_idx < PTRS_PER_PMD && pfn < end_pfn;
> pmd++, pmd_idx++) {
> unsigned int addr = pfn * PAGE_SIZE + PAGE_OFFSET;
>
> /*
> * Map with big pages if possible, otherwise
> * create normal page tables:
> - *
> - * Don't use a large page for the first 2/4MB of memory
> - * because there are often fixed size MTRRs in there
> - * and overlapping MTRRs into large pages can cause
> - * slowdowns.
> */
> - if (cpu_has_pse && !(pgd_idx == 0 && pmd_idx == 0)) {
> + if (use_pse) {
> unsigned int addr2;
> pgprot_t prot = PAGE_KERNEL_LARGE;
>
> @@ -233,13 +232,12 @@ static void __init kernel_physical_mappi
> set_pmd(pmd, pfn_pmd(pfn, prot));
>
> pfn += PTRS_PER_PTE;
> - max_pfn_mapped = pfn;
> continue;
> }
> pte = one_page_table_init(pmd);
>
> for (pte_ofs = 0;
> - pte_ofs < PTRS_PER_PTE && pfn < max_low_pfn;
> + pte_ofs < PTRS_PER_PTE && pfn < end_pfn;
> pte++, pfn++, pte_ofs++, addr += PAGE_SIZE) {
> pgprot_t prot = PAGE_KERNEL;
>
> @@ -249,7 +247,6 @@ static void __init kernel_physical_mappi
> pages_4k++;
> set_pte(pte, pfn_pte(pfn, prot));
> }
> - max_pfn_mapped = pfn;
> }
> }
> update_page_count(PG_LEVEL_2M, pages_2m);
> @@ -729,7 +726,7 @@ void __init setup_bootmem_allocator(void
>
> static void __init find_early_table_space(unsigned long end)
> {
> - unsigned long puds, pmds, tables, start;
> + unsigned long puds, pmds, ptes, tables, start;
>
> puds = (end + PUD_SIZE - 1) >> PUD_SHIFT;
> tables = PAGE_ALIGN(puds * sizeof(pud_t));
> @@ -737,10 +734,15 @@ static void __init find_early_table_spac
> pmds = (end + PMD_SIZE - 1) >> PMD_SHIFT;
> tables += PAGE_ALIGN(pmds * sizeof(pmd_t));
>
> - if (!cpu_has_pse) {
> - int ptes = (end + PAGE_SIZE - 1) >> PAGE_SHIFT;
> - tables += PAGE_ALIGN(ptes * sizeof(pte_t));
> - }
> + if (cpu_has_pse) {
> + int extra;
> + extra = end - ((end>>21) << 21);
>
That's a bit magic. Isn't that just "extra = end & ((1 << 21) - 1)"?
And what are you actually computing here anyway?
> + extra += (2<<20);
>
PMD_SIZE? The comment below says "2/4MB", which corresponds to a
PAE/non-PAE large PMD.
> + ptes = (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
> + } else
> + ptes = (end + PAGE_SIZE - 1) >> PAGE_SHIFT;
> +
> + tables += PAGE_ALIGN(ptes * sizeof(pte_t));
>
> /*
> * RED-PEN putting page tables only on node 0 could
> @@ -766,6 +768,8 @@ unsigned long __init_refok init_memory_m
> unsigned long end)
> {
> pgd_t *pgd_base = swapper_pg_dir;
> + unsigned long start_pfn, end_pfn;
> + unsigned long big_page_start;
>
> /*
> * Find space for the kernel direct mapping tables.
> @@ -790,7 +794,41 @@ unsigned long __init_refok init_memory_m
> __PAGE_KERNEL_EXEC |= _PAGE_GLOBAL;
> }
>
> - kernel_physical_mapping_init(pgd_base, start, end);
> + /*
> + * Don't use a large page for the first 2/4MB of memory
> + * because there are often fixed size MTRRs in there
> + * and overlapping MTRRs into large pages can cause
> + * slowdowns.
> + */
> + big_page_start = 2UL<<20;
>
PMD_SIZE again? Non-PAE big pages are 4MB.
> + if (start < big_page_start) {
> + start_pfn = start >> PAGE_SHIFT;
> + end_pfn = min(big_page_start>>PAGE_SHIFT, end>>PAGE_SHIFT);
> + } else {
> + /* head is not 2M alignment ? */
> + start_pfn = (start >> 21) << (21 - PAGE_SHIFT);
> + end_pfn = start >> PAGE_SHIFT;
> + }
> + if (start_pfn < end_pfn)
> + kernel_physical_mapping_init(pgd_base, start_pfn, end_pfn, 0);
> +
> + /* big page range */
> + start_pfn = ((start + ((2UL<<20) - 1)) >> 21) << (21 - PAGE_SHIFT);
>
More magic.
> + if (start_pfn < (big_page_start >> PAGE_SHIFT))
> + start_pfn = big_page_start >> PAGE_SHIFT;
> + end_pfn = (end >> 21) << (21 - PAGE_SHIFT);
> + if (start_pfn < end_pfn)
> + kernel_physical_mapping_init(pgd_base, start_pfn, end_pfn,
> + cpu_has_pse);
> +
> + /* tail is not 2M alignment ? */
> + start_pfn = end_pfn;
> + if (start_pfn > (big_page_start>>PAGE_SHIFT)) {
> + end_pfn = end >> PAGE_SHIFT;
> + if (start_pfn < end_pfn)
> + kernel_physical_mapping_init(pgd_base, start_pfn,
> + end_pfn, 0);
> + }
I think this code could do with a dose of comments and some symbolic
constants. And perhaps the tactical use of round_up/down.
But it's a nice simplification of kernel_physical_mapping_init().
J
next prev parent reply other threads:[~2008-06-28 17:38 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-26 0:48 [PATCH 00/16] x86: merge setup_32/64.c Yinghai Lu
2008-06-26 0:49 ` [PATCH 03/16] x86: update reserve_initrd to support 64bit Yinghai Lu
2008-06-26 0:50 ` [PATCH 04/16] x86: put global variable for 32bit all together Yinghai Lu
2008-06-26 0:51 ` [PATCH 05/16] x86: add extra includes for 64bit support Yinghai Lu
2008-06-26 0:52 ` [PATCH 06/16] x86: merge 64bit setup_arch into setup_32 Yinghai Lu
2008-06-26 0:53 ` [PATCH 07/16] x86: space to tab in setup_arch Yinghai Lu
2008-06-26 0:54 ` [PATCH 08/16] x86: rename setup_32.c to setup.c Yinghai Lu
2008-06-26 0:55 ` [PATCH 09/16] x86: move boot_params back " Yinghai Lu
2008-06-26 0:56 ` [PATCH 10/16] x86: move parse_setup_data " Yinghai Lu
2008-06-26 0:57 ` [PATCH 11/16] x86: move back crashkernel " Yinghai Lu
2008-06-26 0:58 ` [PATCH 12/16] x86: move reserve_standard_io_resources " Yinghai Lu
2008-06-26 0:58 ` [PATCH 13/16] x86: move parse elfvorehdr " Yinghai Lu
2008-06-26 0:59 ` [PATCH 14/16] x86: make x86_find_smp_config depends on 64 bit too Yinghai Lu
2008-06-26 1:00 ` [PATCH 15/16] x86: change some functions in setup.c to static Yinghai Lu
2008-06-26 1:02 ` [PATCH 16/16] x86: we only have init_pg_tables_end for 32bit Yinghai Lu
2008-06-26 2:52 ` [PATCH] x86: clean up ARCH_SETUP Yinghai Lu
2008-06-26 13:26 ` Ingo Molnar
2008-06-26 4:51 ` [PATCH] x86: move fix mapping page table range early Yinghai Lu
2008-06-26 13:27 ` Ingo Molnar
2008-06-27 6:17 ` [PATCH] x86: early res print out alignment Yinghai Lu
2008-06-27 8:41 ` [PATCH] x86: let setup_arch call init_apic_mappings for 32bit Yinghai Lu
2008-06-28 6:37 ` Ingo Molnar
2008-06-27 22:36 ` [PATCH] x86: early res print out alignment v2 Yinghai Lu
2008-06-28 6:36 ` Ingo Molnar
2008-06-29 4:42 ` Yinghai Lu
2008-06-27 22:38 ` [PATCH] x86: fix init_memory_mapping over boundary Yinghai Lu
2008-06-28 5:47 ` [PATCH] x86: fix init_memory_mapping over boundary v2 Yinghai Lu
2008-06-28 6:35 ` Ingo Molnar
2008-06-28 7:01 ` Yinghai Lu
2008-06-28 7:02 ` Ingo Molnar
2008-06-28 7:19 ` Yinghai Lu
2008-06-28 7:21 ` Ingo Molnar
2008-06-28 7:42 ` Yinghai Lu
2008-06-28 7:22 ` Yinghai Lu
2008-06-28 7:47 ` Ingo Molnar
2008-06-28 10:30 ` Yinghai Lu
2008-06-28 11:07 ` Ingo Molnar
2008-06-28 17:38 ` Jeremy Fitzhardinge [this message]
2008-06-28 20:33 ` Yinghai Lu
2008-06-29 0:49 ` [PATCH] x86: fix init_memory_mapping over boundary v4 Yinghai Lu
2008-06-29 2:22 ` Jeremy Fitzhardinge
2008-06-29 4:40 ` Yinghai Lu
2008-06-29 5:18 ` Jeremy Fitzhardinge
2008-06-29 7:08 ` Ingo Molnar
2008-06-29 7:30 ` Yinghai Lu
2008-06-30 8:33 ` Ingo Molnar
2008-06-29 7:39 ` [PATCH] x86: fix init_memory_mapping over boundary v4 - diff to v3 Yinghai Lu
2008-06-29 9:48 ` Ingo Molnar
2008-06-29 0:49 ` [PATCH] x86: fix warning in e820_reserve_resources with 32bit Yinghai Lu
2008-06-29 9:49 ` Ingo Molnar
2008-06-26 9:47 ` [PATCH 00/16] x86: merge setup_32/64.c Ingo Molnar
2008-06-26 10:02 ` Ingo Molnar
2008-06-26 10:06 ` Yinghai Lu
2008-06-26 11:01 ` Ingo Molnar
2008-06-27 2:51 ` Huang, Ying
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=486676FC.0@goop.org \
--to=jeremy@goop.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=yhlu.kernel@gmail.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.