Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752322AbbGIBmG (ORCPT ); Wed, 8 Jul 2015 21:42:06 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:38034 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752839AbbGIBmA (ORCPT ); Wed, 8 Jul 2015 21:42:00 -0400 MIME-Version: 1.0 In-Reply-To: <20150708174409.GB5598@codeblueprint.co.uk> References: <1436300428-21163-1-git-send-email-yinghai@kernel.org> <1436300428-21163-28-git-send-email-yinghai@kernel.org> <20150708174409.GB5598@codeblueprint.co.uk> Date: Wed, 8 Jul 2015 18:41:59 -0700 Message-ID: Subject: Re: [PATCH 27/42] x86: restore end_of_ram to E820_RAM From: Dan Williams To: Matt Fleming Cc: Yinghai Lu , Kees Cook , "H. Peter Anvin" , Baoquan He , "linux-kernel@vger.kernel.org" , Christoph Hellwig Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2624 Lines: 65 On Wed, Jul 8, 2015 at 10:44 AM, Matt Fleming 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 >> --- >> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/