Re: [PATCH 27/42] x86: restore end_of_ram to E820_RAM

From: Dan Williams
Date: Wed Jul 08 2015 - 21:42:08 EST


On Wed, Jul 8, 2015 at 10:44 AM, Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 07 Jul, at 01:20:13PM, Yinghai Lu wrote:
>> We don't need to create mapping for E820_PRAM.
>>
>> Signed-off-by: Yinghai Lu <yinghai@xxxxxxxxxx>
>> ---
>> 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 a102564..46ec08d 100644
>> --- a/arch/x86/kernel/e820.c
>> +++ b/arch/x86/kernel/e820.c
>> @@ -753,7 +753,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;
>> @@ -764,11 +764,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;
>> @@ -793,12 +789,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)
>
> Could you explain why you no longer want to allow pesistent memory to be
> used in figuring out max_pfn? This partially reverts commit ec776ef6bbe1
> ("x86/mm: Add support for the non-standard protected e820 type").
>

pmem is accessed through the driver or through ->direct_access().
Existing NVDIMM devices are already pushing hundreds of gigabytes
which is too large to provide "struct page" coverage by default.
We're looking at other means to provide "struct page" for pmem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/