Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755127AbbG1Cpg (ORCPT ); Mon, 27 Jul 2015 22:45:36 -0400 Received: from mail-ig0-f173.google.com ([209.85.213.173]:35272 "EHLO mail-ig0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754765AbbG1Cpe (ORCPT ); Mon, 27 Jul 2015 22:45:34 -0400 MIME-Version: 1.0 In-Reply-To: <20150728005242.GB1720@dhcp-17-102.nay.redhat.com> References: <1437304064-9916-1-git-send-email-bhe@redhat.com> <20150719145320.GB9968@dhcp-17-102.nay.redhat.com> <20150721073123.GA30649@dhcp-129-220.nay.redhat.com> <20150721075011.GC16747@dhcp-128-28.nay.redhat.com> <20150721082343.GC30649@dhcp-129-220.nay.redhat.com> <20150721085846.GA23020@dhcp-128-28.nay.redhat.com> <20150722005930.GE1834@dhcp-17-102.nay.redhat.com> <20150728005242.GB1720@dhcp-17-102.nay.redhat.com> Date: Mon, 27 Jul 2015 19:45:34 -0700 X-Google-Sender-Auth: AHMkUXX9V3VpWG09m5bKUw0eqoc Message-ID: Subject: Re: [PATCH v2] Do not reserve crashkernel high memory if crashkernel low memory reserving failed From: Yinghai Lu To: Baoquan He Cc: Dave Young , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Borislav Petkov , Andrew Morton , Jiri Kosina , Vivek Goyal , Linux Kernel Mailing List 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: 1431 Lines: 29 On Mon, Jul 27, 2015 at 5:52 PM, Baoquan He wrote: > On 07/22/15 at 04:47pm, Yinghai Lu wrote: > > Sorry for late reply. This problem is reported by customers. They usulay > don't like to make these things public. While for those systems with > good hard iommu support, it could also fail to initialize hw iommu and > then use swiotlb again, E.g in kdump kernel case. You can see in > intel_iommu_init() swiotlb is assigned to 0 only if intel iommu (namely vt-d) > is initialized successfully. There's possibility that hw iommu > initialization will fail, in this case kdump kernel will fail to boot > if no any low memory is given. So we can't make assumption that system > can boot always well without low memory. When we had crashkernel=,high working with auto low=40M. all system with crashkernel=,high worked. Now come one model (assume it is 16 socket system), and it could use crashkernel=,high crashkernel=256M,low. So it forces all auto_low be 256M. That is ugly. If the customer does not want to make the log public to make us to find good solution, why should we care about it ? why not just let them carry the "crashkernel=256M,low" all the way? Yinghai -- 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/