'Commit ec776ef6bbe17 ("x86/mm: Add support for the non-standard
protected e820 type")' added E820_PRAM ranges, which do not have
have struct-page. Therefore, there is no need to update max_pfn
to cover the E820_PRAM ranges. Revert the change made to account
E820_PRAM as RAM in e820.c in the commit.
Signed-off-by: Yinghai Lu <[email protected]>
Signed-off-by: Toshi Kani <[email protected]>
Tested-by: Christoph Hellwig <[email protected]>
---
The patch is based on the tip branch.
---
arch/x86/kernel/e820.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index e2ce85d..e09a346 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -752,7 +752,7 @@ u64 __init early_reserve_e820(u64 size, u64 align)
/*
* Find the highest page frame number we have available
*/
-static unsigned long __init e820_end_pfn(unsigned long limit_pfn)
+static unsigned long __init e820_end_pfn(unsigned long limit_pfn, unsigned type)
{
int i;
unsigned long last_pfn = 0;
@@ -763,11 +763,7 @@ static unsigned long __init e820_end_pfn(unsigned long limit_pfn)
unsigned long start_pfn;
unsigned long end_pfn;
- /*
- * Persistent memory is accounted as ram for purposes of
- * establishing max_pfn and mem_map.
- */
- if (ei->type != E820_RAM && ei->type != E820_PRAM)
+ if (ei->type != type)
continue;
start_pfn = ei->addr >> PAGE_SHIFT;
@@ -792,12 +788,12 @@ static unsigned long __init e820_end_pfn(unsigned long limit_pfn)
}
unsigned long __init e820_end_of_ram_pfn(void)
{
- return e820_end_pfn(MAX_ARCH_PFN);
+ return e820_end_pfn(MAX_ARCH_PFN, E820_RAM);
}
unsigned long __init e820_end_of_low_ram_pfn(void)
{
- return e820_end_pfn(1UL << (32-PAGE_SHIFT));
+ return e820_end_pfn(1UL<<(32 - PAGE_SHIFT), E820_RAM);
}
static void early_panic(char *msg)
On 04/06/2015 10:00 PM, Toshi Kani wrote:
> 'Commit ec776ef6bbe17 ("x86/mm: Add support for the non-standard
> protected e820 type")' added E820_PRAM ranges, which do not have
> have struct-page. Therefore, there is no need to update max_pfn
> to cover the E820_PRAM ranges.
But E820_PRAM ranges will have the possibility for struct-page.
That said I have tested with this patch + struct-page and
Tested-by: Boaz Harrosh <[email protected]>
Comments below ...
> Revert the change made to account
> E820_PRAM as RAM in e820.c in the commit.
>
> Signed-off-by: Yinghai Lu <[email protected]>
> Signed-off-by: Toshi Kani <[email protected]>
> Tested-by: Christoph Hellwig <[email protected]>
> ---
> The patch is based on the tip branch.
> ---
> arch/x86/kernel/e820.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index e2ce85d..e09a346 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -752,7 +752,7 @@ u64 __init early_reserve_e820(u64 size, u64 align)
> /*
> * Find the highest page frame number we have available
> */
> -static unsigned long __init e820_end_pfn(unsigned long limit_pfn)
> +static unsigned long __init e820_end_pfn(unsigned long limit_pfn, unsigned type)
Why don't you rename it to say e820_max_ram_pfn or something with ram
as you noted, and drop the @type. As Christoph said it is very ugly. You do not
put an extra parameter because of a bad name?
Anyway you are changing all call sites so it will not even be a bigger
change
> {
> int i;
> unsigned long last_pfn = 0;
> @@ -763,11 +763,7 @@ static unsigned long __init e820_end_pfn(unsigned long limit_pfn)
> unsigned long start_pfn;
> unsigned long end_pfn;
>
> - /*
> - * Persistent memory is accounted as ram for purposes of
> - * establishing max_pfn and mem_map.
> - */
> - if (ei->type != E820_RAM && ei->type != E820_PRAM)
> + if (ei->type != type)
> continue;
>
> start_pfn = ei->addr >> PAGE_SHIFT;
> @@ -792,12 +788,12 @@ static unsigned long __init e820_end_pfn(unsigned long limit_pfn)
> }
> unsigned long __init e820_end_of_ram_pfn(void)
> {
> - return e820_end_pfn(MAX_ARCH_PFN);
> + return e820_end_pfn(MAX_ARCH_PFN, E820_RAM);
> }
>
> unsigned long __init e820_end_of_low_ram_pfn(void)
> {
> - return e820_end_pfn(1UL << (32-PAGE_SHIFT));
> + return e820_end_pfn(1UL<<(32 - PAGE_SHIFT), E820_RAM);
> }
>
> static void early_panic(char *msg)
>
Thanks
Boaz
On Tue, Apr 07, 2015 at 09:36:37AM +0300, Boaz Harrosh wrote:
> On 04/06/2015 10:00 PM, Toshi Kani wrote:
> > 'Commit ec776ef6bbe17 ("x86/mm: Add support for the non-standard
> > protected e820 type")' added E820_PRAM ranges, which do not have
> > have struct-page. Therefore, there is no need to update max_pfn
> > to cover the E820_PRAM ranges.
>
> But E820_PRAM ranges will have the possibility for struct-page.
>
> That said I have tested with this patch + struct-page and
I'd love to resurrect the old "real page backed" pmem support from
the old Intel patches eventually, but with all the arguments on
how we should do I/O on pmem I'd like to keep that a Ń•eparate
discussion. And leaving only fragments of some support in is a bad
idea, so sorry for letting all this slip through..
> > -static unsigned long __init e820_end_pfn(unsigned long limit_pfn)
> > +static unsigned long __init e820_end_pfn(unsigned long limit_pfn, unsigned type)
>
> Why don't you rename it to say e820_max_ram_pfn or something with ram
> as you noted, and drop the @type. As Christoph said it is very ugly. You do not
> put an extra parameter because of a bad name?
>
> Anyway you are changing all call sites so it will not even be a bigger
> change
It's a static function, and we have much worse naming sins in public
ones, so I'm not worried about a _ram more or less. But if people feel
stronly about it I'm fine with adding the _ram.
I feel pretty stronly against adding back a pointless argument, though.
On Tue, 2015-04-07 at 09:04 +0200, Christoph Hellwig wrote:
> On Tue, Apr 07, 2015 at 09:36:37AM +0300, Boaz Harrosh wrote:
> > On 04/06/2015 10:00 PM, Toshi Kani wrote:
> > > 'Commit ec776ef6bbe17 ("x86/mm: Add support for the non-standard
> > > protected e820 type")' added E820_PRAM ranges, which do not have
> > > have struct-page. Therefore, there is no need to update max_pfn
> > > to cover the E820_PRAM ranges.
> >
> > But E820_PRAM ranges will have the possibility for struct-page.
> >
> > That said I have tested with this patch + struct-page and
>
> I'd love to resurrect the old "real page backed" pmem support from
> the old Intel patches eventually, but with all the arguments on
> how we should do I/O on pmem I'd like to keep that a Ń•eparate
> discussion. And leaving only fragments of some support in is a bad
> idea,
Agreed -- it should be a separate discussion and we need to get it
straight for 4.1.
> so sorry for letting all this slip through..
No problem.
> > > -static unsigned long __init e820_end_pfn(unsigned long limit_pfn)
> > > +static unsigned long __init e820_end_pfn(unsigned long limit_pfn, unsigned type)
> >
> > Why don't you rename it to say e820_max_ram_pfn or something with ram
> > as you noted, and drop the @type. As Christoph said it is very ugly. You do not
> > put an extra parameter because of a bad name?
> >
> > Anyway you are changing all call sites so it will not even be a bigger
> > change
>
> It's a static function, and we have much worse naming sins in public
> ones, so I'm not worried about a _ram more or less. But if people feel
> stronly about it I'm fine with adding the _ram.
>
> I feel pretty stronly against adding back a pointless argument, though.
We should keep this patch as a revert/fix, and should not combine with
other cleanup. Adding the _ram, etc. can be done as a separate change.
Thanks,
-Toshi