* [PATCH v2] x86: Revert E820_PRAM change in e820_end_pfn()
@ 2015-04-06 19:00 Toshi Kani
2015-04-07 6:36 ` Boaz Harrosh
0 siblings, 1 reply; 4+ messages in thread
From: Toshi Kani @ 2015-04-06 19:00 UTC (permalink / raw)
To: mingo, hpa, tglx
Cc: linux-nvdimm, linux-fsdevel, x86, linux-kernel, hch, boaz,
Yinghai Lu, Toshi Kani
'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 <yinghai@kernel.org>
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Tested-by: Christoph Hellwig <hch@lst.de>
---
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)
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v2] x86: Revert E820_PRAM change in e820_end_pfn()
2015-04-06 19:00 [PATCH v2] x86: Revert E820_PRAM change in e820_end_pfn() Toshi Kani
@ 2015-04-07 6:36 ` Boaz Harrosh
2015-04-07 7:04 ` Christoph Hellwig
0 siblings, 1 reply; 4+ messages in thread
From: Boaz Harrosh @ 2015-04-07 6:36 UTC (permalink / raw)
To: Toshi Kani, mingo, hpa, tglx
Cc: linux-nvdimm, linux-fsdevel, x86, linux-kernel, hch, Yinghai Lu
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 <boaz@plexistor.com>
Comments below ...
> Revert the change made to account
> E820_PRAM as RAM in e820.c in the commit.
>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> Signed-off-by: Toshi Kani <toshi.kani@hp.com>
> Tested-by: Christoph Hellwig <hch@lst.de>
> ---
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] x86: Revert E820_PRAM change in e820_end_pfn()
2015-04-07 6:36 ` Boaz Harrosh
@ 2015-04-07 7:04 ` Christoph Hellwig
2015-04-07 13:51 ` Toshi Kani
0 siblings, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2015-04-07 7:04 UTC (permalink / raw)
To: Boaz Harrosh
Cc: Toshi Kani, mingo, hpa, tglx, linux-nvdimm, linux-fsdevel, x86,
linux-kernel, hch, Yinghai Lu
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] x86: Revert E820_PRAM change in e820_end_pfn()
2015-04-07 7:04 ` Christoph Hellwig
@ 2015-04-07 13:51 ` Toshi Kani
0 siblings, 0 replies; 4+ messages in thread
From: Toshi Kani @ 2015-04-07 13:51 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Boaz Harrosh, mingo, hpa, tglx, linux-nvdimm, linux-fsdevel, x86,
linux-kernel, Yinghai Lu
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-04-07 14:09 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-06 19:00 [PATCH v2] x86: Revert E820_PRAM change in e820_end_pfn() Toshi Kani
2015-04-07 6:36 ` Boaz Harrosh
2015-04-07 7:04 ` Christoph Hellwig
2015-04-07 13:51 ` Toshi Kani
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).