<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>Re: kdump info request</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Will try.<BR>
<BR>
Thanks<BR>
Atul<BR>
<BR>
<BR>
----- Original Message -----<BR>
From: Randy Dunlap <rdunlap@xenotime.net><BR>
To: Mukker, Atul<BR>
Cc: vgoyal@in.ibm.com <vgoyal@in.ibm.com>; Moore, Eric; Kexec Mailing List <kexec@lists.infradead.org><BR>
Sent: Sat Sep 22 12:35:53 2007<BR>
Subject: Re: kdump info request<BR>
<BR>
On Fri, 21 Sep 2007 06:48:01 -0600 Mukker, Atul wrote:<BR>
<BR>
> One more question, and hopefully I will not bug you further on this :-)<BR>
><BR>
> How exactly do you parse the kernel parameters? I thought it would be<BR>
> plain simple, but seems like the command line string is not available to<BR>
> SCSI driver like ours, or I am missing something?<BR>
<BR>
#include <linux/init.h> // for extern of 'saved_command_line' pointer.<BR>
<BR>
and use calls to any functions in lib/cmdline.c or write your<BR>
own functions. Should be fairly simple to scan for a fixed string<BR>
of "elfcorehdr=".<BR>
You don't care about the variable parameters.. or do you?<BR>
<BR>
<BR>
> Thanks<BR>
> -Atul<BR>
><BR>
> -----Original Message-----<BR>
> From: Vivek Goyal [<A HREF="mailto:vgoyal@in.ibm.com">mailto:vgoyal@in.ibm.com</A>]<BR>
> Sent: Friday, September 21, 2007 12:15 AM<BR>
> To: Mukker, Atul<BR>
> Cc: Kexec Mailing List; Moore, Eric<BR>
> Subject: Re: kdump info request<BR>
><BR>
> On Wed, Sep 19, 2007 at 07:26:19AM -0600, Mukker, Atul wrote:<BR>
> [..]<BR>
> > ><BR>
> > > If we could somehow determine that we are being called in context of<BR>
> > capture kernel, we can dynamically lower driver memory requirement (at<BR>
> > cost of lower IO throughout of-course, which is ok for this brief<BR>
> > context).<BR>
> ><BR>
> > You can parse the command line and look for presence of elfcorehdr=<BR>
> > option.<BR>
> > This is internally appended to command line by kexec tools to tell<BR>
> > capture<BR>
> > kernel the address of ELF core headers.<BR>
> ><BR>
> ><BR>
> > [AM] Is this a standard way? Doesn't look like one. According to<BR>
> > kernel-parameters.txt, kexec would "generally" pass this option to<BR>
> > kernel command line. Can we look at "struct resource crashk_res" and<BR>
> > check if start and end member have different value, which indicates<BR>
> > capture kernel?<BR>
> ><BR>
><BR>
> Well, nobody else so far has had such requirements so can't say if this<BR>
> is standard way. But this is the best way I can think of so far.<BR>
><BR>
> Using crashk_res will not work. Not all users will use kdump and will<BR>
> not<BR>
> reserve any memory for capture kernel. In that case crashk_res will be<BR>
> zero for start and end and you don't want to trim down the functionality<BR>
> of your driver.<BR>
><BR>
> > What's the memory allocation requirement of current RAID driver? How<BR>
> > much<BR>
> > memory you are reserving for capture kernel? Are you already seeing<BR>
> the<BR>
> > memory allocation failure?<BR>
> ><BR>
> > [AM] Our normal runtime memory is about 20MB. For the test beds, we<BR>
> use<BR>
> > "crashkernel=192M@16M". We have not yet seen the allocation failure<BR>
> but<BR>
> > we would like to build the fallback mechanism if it does fail under<BR>
> > capture kernel. Only if we are not able to get the normal runtime<BR>
> > memory, we plan to switch to a lower memory model.<BR>
> ><BR>
><BR>
> 20MB is huge. I agree that it is a good idea to bring it down for<BR>
> capture<BR>
> kernel if performance is not significantly impacted.<BR>
><BR>
> > I feel until and unless memory requirements are huge, we should not<BR>
> > compromise with IO throughput. Capability to save the dump to disk as<BR>
> > fast<BR>
> > as possible to reduce the down time is also an important<BR>
> consideration.<BR>
> ><BR>
> > [AM] We believe our normal runtime memory requirement is significant.<BR>
> > Also, even with the lower memory, there would not be a noticeable dump<BR>
> > time difference since lot of memory is for supporting multiple<BR>
> > outstanding commands in driver's raid core and other raid operations,<BR>
> > which will not be running under capture kernel. Thanks again for your<BR>
> > feedback.<BR>
> ><BR>
><BR>
> Makes sense.<BR>
><BR>
> Thanks<BR>
> Vivek<BR>
><BR>
> _______________________________________________<BR>
> kexec mailing list<BR>
> kexec@lists.infradead.org<BR>
> <A HREF="http://lists.infradead.org/mailman/listinfo/kexec">http://lists.infradead.org/mailman/listinfo/kexec</A><BR>
><BR>
<BR>
<BR>
---<BR>
~Randy<BR>
*** Remember to use Documentation/SubmitChecklist when testing your code ***<BR>
</FONT>
</P>
</BODY>
</HTML>