Re: [PATCH] [6/8] Account overlapped mappings in end_pfn_map

2008-02-11 Thread Arjan van de Ven
On Mon, 11 Feb 2008 10:34:34 +0100 (CET) Andi Kleen <[EMAIL PROTECTED]> 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. we need to fix this btw; mapping memory that doesn't really exist is a rather

Re: [PATCH] [6/8] Account overlapped mappings in end_pfn_map

2008-02-11 Thread Sam Ravnborg
> > _pfn is variant of hungarian notation (just postfix instead of prefix); > that is why I referred to it. > > Admittedly it was a little unfair pun with Ingo, but he really > asked for it in this case :-) I thought it was a good joke! It made me smile. Sam -- To unsubscribe from

Re: [PATCH] [6/8] Account overlapped mappings in end_pfn_map

2008-02-11 Thread Andi Kleen
On Monday 11 February 2008 15:16:31 Peter Zijlstra wrote: > > On Mon, 2008-02-11 at 14:27 +0100, Andi Kleen wrote: > > > Ok patch with hungarized variables appended. > > > -static void __meminit > > +static unsigned long __meminit > > phys_pmd_update(pud_t *pud, unsigned long address, unsigned

Re: [PATCH] [6/8] Account overlapped mappings in end_pfn_map

2008-02-11 Thread Peter Zijlstra
On Mon, 2008-02-11 at 14:27 +0100, Andi Kleen wrote: > Ok patch with hungarized variables appended. > -static void __meminit > +static unsigned long __meminit > phys_pmd_update(pud_t *pud, unsigned long address, unsigned long end) > { > + unsigned long true_end; > pmd_t *pmd =

Re: [PATCH] [6/8] Account overlapped mappings in end_pfn_map

2008-02-11 Thread Ingo Molnar
* Andi Kleen <[EMAIL PROTECTED]> wrote: > > your patch is also a bit unclean: > > Ok patch with hungarized variables appended. My comments have nothing to do with "hungarized variables". You used clearly unclean and ambigious coding constructs like: +static unsigned long __meminit

Re: [PATCH] [6/8] Account overlapped mappings in end_pfn_map

2008-02-11 Thread Andi Kleen
On Monday 11 February 2008 14:08:43 Ingo Molnar wrote: > > * Andi Kleen <[EMAIL PROTECTED]> 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? Yes EFI needs

Re: [PATCH] [6/8] Account overlapped mappings in end_pfn_map

2008-02-11 Thread Ingo Molnar
* Andi Kleen <[EMAIL PROTECTED]> 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

[PATCH] [6/8] Account overlapped mappings in end_pfn_map

2008-02-11 Thread Andi Kleen
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. This is needed for other code that needs to know the true mapping alias state (in this case EFI). But it's also more correct in general Cc: [EMAIL PROTECTED]

Re: [PATCH] [6/8] Account overlapped mappings in end_pfn_map

2008-02-11 Thread Ingo Molnar
* Andi Kleen [EMAIL PROTECTED] wrote: your patch is also a bit unclean: Ok patch with hungarized variables appended. My comments have nothing to do with hungarized variables. You used clearly unclean and ambigious coding constructs like: +static unsigned long __meminit

Re: [PATCH] [6/8] Account overlapped mappings in end_pfn_map

2008-02-11 Thread Sam Ravnborg
_pfn is variant of hungarian notation (just postfix instead of prefix); that is why I referred to it. Admittedly it was a little unfair pun with Ingo, but he really asked for it in this case :-) I thought it was a good joke! It made me smile. Sam -- To unsubscribe from this

Re: [PATCH] [6/8] Account overlapped mappings in end_pfn_map

2008-02-11 Thread Peter Zijlstra
On Mon, 2008-02-11 at 14:27 +0100, Andi Kleen wrote: Ok patch with hungarized variables appended. -static void __meminit +static unsigned long __meminit phys_pmd_update(pud_t *pud, unsigned long address, unsigned long end) { + unsigned long true_end; pmd_t *pmd =

Re: [PATCH] [6/8] Account overlapped mappings in end_pfn_map

2008-02-11 Thread Andi Kleen
On Monday 11 February 2008 14:08:43 Ingo Molnar wrote: * Andi Kleen [EMAIL PROTECTED] 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? Yes EFI needs to know

Re: [PATCH] [6/8] Account overlapped mappings in end_pfn_map

2008-02-11 Thread Ingo Molnar
* Andi Kleen [EMAIL PROTECTED] 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

[PATCH] [6/8] Account overlapped mappings in end_pfn_map

2008-02-11 Thread Andi Kleen
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. This is needed for other code that needs to know the true mapping alias state (in this case EFI). But it's also more correct in general Cc: [EMAIL PROTECTED]

Re: [PATCH] [6/8] Account overlapped mappings in end_pfn_map

2008-02-11 Thread Andi Kleen
On Monday 11 February 2008 15:16:31 Peter Zijlstra wrote: On Mon, 2008-02-11 at 14:27 +0100, Andi Kleen wrote: Ok patch with hungarized variables appended. -static void __meminit +static unsigned long __meminit phys_pmd_update(pud_t *pud, unsigned long address, unsigned long end)