Message-ID: <20130401192606.GA17951@redhat.com>
Date:	Mon, 1 Apr 2013 15:26:06 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	WANG Chao <chaowang@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org, Yinghai Lu <yinghai@...nel.org>
Subject: Re: [PATCH] kexec: use Crash kernel for Crash kernel low

On Mon, Apr 01, 2013 at 11:33:13AM -0700, H. Peter Anvin wrote:
> On 04/01/2013 06:34 AM, Vivek Goyal wrote:
> > On Tue, Mar 26, 2013 at 02:14:18PM -0400, Vivek Goyal wrote:
> >> On Mon, Mar 25, 2013 at 02:50:18PM -0700, Yinghai Lu wrote:
> >>> On Mon, Mar 25, 2013 at 12:42 PM, Vivek Goyal <vgoyal@...hat.com> wrote:
> >>>> So it is a forgone conclusion that these new kernel changes to
> >>>> crashkernel=X in 3.9 are incompatible with older kexec-tools and one
> >>>> needs to upgrade kexec-tools.
> >>>
> >>> I thought that you and hpa all agreed that user need to update kexec-tools with
> >>> new kernel v3.9. It that still right?
> >>
> >> I can update kexec-tools and I don't have problems with that. I am only
> >> concerned about some xyz user complaining that new kernel stopped working
> >> with old kexec-tools and then possibly face the rant from Linus about
> >> breaking user space. :-)
> >>
> >> To me we could maintain backward compatibility by retaining the existing
> >> behavior of crashkernle=X. That is  look for specificied memory below
> >> 896M first and then go higher.
> >>
> >> And hide new semantics behind new kernel parameters or by extending
> >> existing parameter (say crashkernel=X:search_high_first) to specify how
> >> to search for reserved memory.
> >>
> >> In both the cases we should probably retain the logic of auto reserving
> >> low memory for software iotlb and let user opt out if there is no need.
> >>
> >> So we don't have a strong reason that why we should break existing
> >> kexec-tools. So I would prefer not to break it.
> >>
> >> But I think this is hpa's decision.
> > 
> > hpa,
> > 
> > ping. Any thoughts on this?
> 
> Pardon me while I retch.  The whole kdump dependency mess is making me
> sick to my stomach.
> 
> The fundamental problem you have is that the user has to take an action
> that doesn't make any sense, because there isn't any sane method to
> backflow the requirements from the crashkernel to the command line.
> 
> The only way I can think how to deal with that in a sane way that
> doesn't require that the user has to understand a whole bunch of things
> about their system that no user should ever have to be burdened with is
> to have the packaging system feed back information about the crashkernel
> and kexec-tools that will be used.  That interface probably needs
> serious architecting.
> 
> I wouldn't object to crashkernel=<size>,<option>,<option>... being the
> format for that and it has the plus that it doesn't break less.  So
> something like "crashkernel=800M,high" (:search_high_first is
> inconsistent with other options and completely pointlessly wordy... this
> isn't Multics, and the command line space is a limited resource) would
> make sense.
> 
> However, I really strongly suggest you work on a mechanism to take the
> information about the crashkernel and utilities that the kernel can't
> know and feed it into the bootloader configuration.  This can be as
> simple as a set of scripts.

Hi Peter,

I agree that this dependency on crashkernel is creating lots of problems
and there should be a better way to manage it.

Sorry, but I did not fully understand your suggestion on how to handle the
problem. IIUC, you are suggesting that kexec-tools has the memory
requirements and when that package installs, it should automatically
update boot loader command line to communicate that requirement to kernel?
Or are you suggesting something else entirely.

Where to reserve is not entirely tied to kexec-tools version. It also
depends on the environment and run time user options. 

For example kernel image being loaded and entry point selected. So if one
decides to load take 32bit entry point of bzImage then memory has to be
reserved in first 4G (despite the fact that kexec-tools is able to load 64bit
bzImage and handle higher reserved ranges).

Also whether to reserve memory for software iotlb will depend on whether
we have chosen to enable iommu in second kernel or not.

So sorting out all the memory reservation requirements based on
kexec-tools version and during installation time alone might not work.

To make user's life easier, we can probably modify "kdump" service and
provide another option which can calculate the right crashkernel= command
line option based on user selected option and system environment and
display it to user (or possibly propogate to bootloader command line and
system is rebooted).

All this will only address the issue of where to reserve memory. It will
still not solve the issue of how much memory to reserve. We have no way
to know. It is all heuristics.

crashkernel=<size>,<option>,<option>.. and crashkernel=800M,high sound
good to me. 

So atleast for 3.9 kernel, shall we hide new semantics behind
crashkernel=XM,high and by default crashkernel=XM tries to emulate
crashkernel=XM,low to retain backward compatibility?

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists