All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Andi Kleen <ak@suse.de>
Cc: ying.huang@intel.com, tglx@linutronix.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [6/8] Account overlapped mappings in end_pfn_map
Date: Mon, 11 Feb 2008 14:08:43 +0100	[thread overview]
Message-ID: <20080211130843.GC23733@elte.hu> (raw)
In-Reply-To: <20080211093434.E30961B41CE@basil.firstfloor.org>


* Andi Kleen <ak@suse.de> wrote:

> When end_pfn is not aligned to 2MB (or 1GB) then the kernel might map 
> more memory than end_pfn. Account this in end_pfn_mapped.

can you see any practical relevance? Your patch description only deals 
with the mechanical details of the change instead of analyzing the most 
important thing: relevance and impact analysis. That makes it harder to 
add your patches and easier to miss a good fix accidentally. It also 
makes it quite a bit harder to trust your patches.

at a quick glance the relevance is to EFI only, in 
efi_enter_virtual_mode(). max_pfn_mapped is used as a differentiator 
between __va() and efi_ioremap(). AFAICS EFI will typically have its 
runtime code not right after the end of physical memory.

Nevertheless, i do agree that the max_pfn_mapped/end_pfn_map limit needs 
to be sharpened to reflect reality (for later PAT support).

your patch is also a bit unclean:

> -static void __meminit
> +static unsigned long __meminit
>  phys_pmd_update(pud_t *pud, unsigned long address, unsigned long end)
>  {
> +	unsigned long r;
>  	pmd_t *pmd = pmd_offset(pud, 0);
>  	spin_lock(&init_mm.page_table_lock);
> -	phys_pmd_init(pmd, address, end);
> +	r = phys_pmd_init(pmd, address, end);
>  	spin_unlock(&init_mm.page_table_lock);
>  	__flush_tlb_all();
> +	return r;
>  }

a meaningless "r" parameter. Use "true_end" instead.

and here's another type of variable naming problem:

> +unsigned long __init_refok
> +init_memory_mapping(unsigned long start, unsigned long end)
>  {
> -	unsigned long next;
> +	unsigned long next, true_end = end;

that "true_end" is already a _pfn_, so name it accordingly: 
true_end_pfn. Because we switch between pfn and addr types it's 
important to point out where it's pfn and where it's a linear/physical 
address.

>  	struct zone *zone = pgdat->node_zones + ZONE_NORMAL;
>  	unsigned long start_pfn = start >> PAGE_SHIFT;
>  	unsigned long nr_pages = size >> PAGE_SHIFT;
> +	unsigned long r;
>  	int ret;
>  
> -	init_memory_mapping(start, start + size-1);
> +	r = init_memory_mapping(start, start + size-1);
> +	if (r > end_pfn_map)
> +		end_pfn_map = r;

rename "r" to "true_end_pfn".

	Ingo

  reply	other threads:[~2008-02-11 13:09 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-11  9:34 [PATCH] [0/8] Various kernel mapping bug fixes Andi Kleen
2008-02-11  9:34 ` [PATCH] [1/8] CPA: Fix gbpages support in try_preserve_lage_page Andi Kleen
2008-02-11  9:45   ` Thomas Gleixner
2008-02-11 10:12     ` Ingo Molnar
2008-02-11 11:01       ` Andi Kleen
2008-02-11  9:34 ` [PATCH] [2/8] CPA: Flush the caches when setting pages not present Andi Kleen
2008-02-11 11:00   ` Ingo Molnar
2008-02-11 12:26     ` Andi Kleen
2008-02-11  9:34 ` [PATCH] [3/8] CPA: Test the correct mapping alias on x86-64 Andi Kleen
2008-02-11 11:49   ` Ingo Molnar
2008-02-11  9:34 ` [PATCH] [4/8] CPA: Fix set_memory_x for ioremap Andi Kleen
2008-02-11 12:27   ` Ingo Molnar
2008-02-11 12:45     ` Andi Kleen
2008-02-11  9:34 ` [PATCH] [5/8] Fix logic error in 64bit memory hotadd Andi Kleen
2008-02-11 12:46   ` Ingo Molnar
2008-02-11 13:05     ` Andi Kleen
2008-02-11 13:33       ` Ingo Molnar
2008-02-11 13:44         ` Andi Kleen
2008-02-12 10:35       ` Yasunori Goto
2008-02-12 11:20         ` Andi Kleen
2008-02-11  9:34 ` [PATCH] [6/8] Account overlapped mappings in end_pfn_map Andi Kleen
2008-02-11 13:08   ` Ingo Molnar [this message]
2008-02-11 13:27     ` Andi Kleen
2008-02-11 13:55       ` Ingo Molnar
2008-02-11 14:16       ` Peter Zijlstra
2008-02-11 14:24         ` Andi Kleen
2008-02-11 14:41           ` Sam Ravnborg
2008-02-11 15:12   ` Arjan van de Ven
2008-02-11  9:34 ` [PATCH] [7/8] Implement true end_pfn_mapped for 32bit Andi Kleen
2008-02-12 19:39   ` Thomas Gleixner
2008-02-12 19:49     ` Andi Kleen
2008-02-12 20:25       ` Thomas Gleixner
2008-02-11  9:34 ` [PATCH] [8/8] RFC: Fix some EFI problems Andi Kleen
2008-02-12 20:04   ` Thomas Gleixner
2008-02-12 20:23     ` Andi Kleen
2008-02-12 20:48       ` Thomas Gleixner
2008-02-13 11:05         ` Andi Kleen

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=20080211130843.GC23733@elte.hu \
    --to=mingo@elte.hu \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=ying.huang@intel.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.