Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760895Ab3DBNue (ORCPT ); Tue, 2 Apr 2013 09:50:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4576 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760607Ab3DBNud (ORCPT ); Tue, 2 Apr 2013 09:50:33 -0400 Date: Tue, 2 Apr 2013 09:50:01 -0400 From: Vivek Goyal To: Yinghai Lu Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , WANG Chao , "Eric W. Biederman" , Linux Kernel Mailing List Subject: Re: [PATCH] kexec: use Crash kernel for Crash kernel low Message-ID: <20130402135001.GC29506@redhat.com> References: <20130401133428.GA13499@redhat.com> <5159D2E9.7080707@zytor.com> <20130401192606.GA17951@redhat.com> <5159F27E.7060300@zytor.com> <515A03DB.6040107@zytor.com> <515A083B.7050508@zytor.com>

MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2712 Lines: 68 On Mon, Apr 01, 2013 at 06:11:38PM -0700, Yinghai Lu wrote: > On Mon, Apr 1, 2013 at 3:40 PM, Yinghai Lu wrote: > > On Mon, Apr 1, 2013 at 3:20 PM, H. Peter Anvin wrote: > >> On 04/01/2013 03:17 PM, Yinghai Lu wrote: > >>> > >>> And his last suggestion is just as his old second suggestion. > >>> > >>> I just check the code again, it looks it is easy to change it to support: > >>> 1. crashkernel=XM > >>> 2. crashkernel_high=XM > >>> 3. crashkernel_high=XM crashkernel_low=YM > >>> > >> > >> Yes... my objections that you are giving the user the headache of > >> dealing with this very much remains, but I don't think we have any good > >> options. However, the ,.... syntax is at least > >> extensible, which the above syntax is not. > > > > ok, will check crashkernel=XM,high > > Please check attached four patches that should get into upstream for 3.9. > I sent first and second before. > other two is addressing old kexec-tools with kdump on new kernel. Hi Yinghai, I think there is still little confusion. What does crashkernel=X,high mean. Currently it seems to mean that memory is allocated from region above 4G and if it is not available, allocation fails. I thought what would be more useful if it means that we start search for memory from higher range of addresses and continue down till we find a suitable memory area. That means memory could either come from higher memory regions (above 4G) or from low memory regions (below 4G) depending on how much physical RAM system has. Similary crashkernel=X or crashkernel=X,low will mean that we start scanning for free memory from low memory area first. And if sufficient amount of memory is not available below 4G, memory could very well come from above 4G. That way a distribution could decide its default memory requirement (say 128M) and they could simply say, crashkernel=128M or crashkernel=128M,high (depending on whether they support 64bit bzImage or not). To achieve the behavior where we want to enforce that memory either comes from low or high area only otherwise allocation fails, we could probably use. crashkernel=X,high_only crashkernel=X,low_only And crashkernel_low could be replaced with crashkernel=X,low_only I think it is reasonable to continue to reserve low memory automatically for swiotlb if crash memory reservation happens above 4G. Users should be able to opt out of it using crashkernel=0M,low_only. Thanks Vivek -- 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/