| Message ID | 1428346839-11997-1-git-send-email-toshi.kani@hp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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)
'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(-) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html