From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932533AbdEDBmC (ORCPT ); Wed, 3 May 2017 21:42:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40126 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932496AbdEDBlt (ORCPT ); Wed, 3 May 2017 21:41:49 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8848683F45 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=xlpang@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 8848683F45 From: Xunlei Pang To: linux-kernel@vger.kernel.org, Ingo Molnar Cc: kexec@lists.infradead.org, akpm@linux-foundation.org, Eric Biederman , Dave Young , x86@kernel.org, Borislav Petkov , Thomas Gleixner , Yinghai Lu , "H. Peter Anvin" , Andy Lutomirski , Xunlei Pang Subject: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity mapping if available Date: Thu, 4 May 2017 09:42:51 +0800 Message-Id: <1493862171-8799-2-git-send-email-xlpang@redhat.com> In-Reply-To: <1493862171-8799-1-git-send-email-xlpang@redhat.com> References: <1493862171-8799-1-git-send-email-xlpang@redhat.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 04 May 2017 01:41:48 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Kexec setups all identity mappings before booting into the new kernel, and this will cause extra memory consumption for paging structures which is quite considerable on modern machines with huge number of memory. E.g. On one 32TB machine, in kdump case, it could waste around 128MB (around 4MB/TB) from the reserved memory after kexec set all the identity mappings using the current 2MB page, plus the loaded kdump kernel, initramfs, etc, it caused kexec syscall -NOMEM failure. As a result, we had to enlarge reserved memory via "crashkernel=X". This causes some trouble for distributions that use policies to evaluate the proper "crashkernel=X" value for users. Given that on machines with large number of memory, 1GB feature is very likely available, and that kernel_ident_mapping_init() supports PUD level 1GB page, to solve this problem, we use 1GB size page to create the identity mapping pgtable for kdump if 1GB feature is available. Signed-off-by: Xunlei Pang --- arch/x86/kernel/machine_kexec_64.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c index 1d4f2b0..c25d277 100644 --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -122,6 +122,10 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable) level4p = (pgd_t *)__va(start_pgtable); clear_page(level4p); + + if (direct_gbpages) + info.direct_gbpages = true; + for (i = 0; i < nr_pfn_mapped; i++) { mstart = pfn_mapped[i].start << PAGE_SHIFT; mend = pfn_mapped[i].end << PAGE_SHIFT; -- 1.8.3.1