Re: kdump info request

Re: kdump info request

[Vivek Goyal]

On Tue, Sep 18, 2007 at 03:13:42PM -0600, Mukker, Atul wrote:
> Hello Vivek, Hari:
> 
>  
> 
> Excuse me for contacting you direct, but seems like you 2 can point me
> to a right direction for a kdump question we have.
> 
>  
> 
> We are trying to make sure our RAID driver works ok when kernel is
> loaded with kdump. Is there a way for driver to detect this condition;
> that is, current kernel is running with kdump. We need this information
> so we can scale down certain operations in the driver.
> 

Hi Atul,

What do you mean by detecting if current kernel is running with kdump? Do 
you mean that you want to know the moment somebody loads a capture kernel
by kexec -p and driver will change some of its behaviour?

I think that's not the right way to go about. Explain the issue
a little bit in detail.

Generally drivers run into issues while initializing in second kernel and
one of the way to handle it is reset the device before going further with
initialization. I am hoping your RAID controller provides some kind of
reset mechanism from software.

Thanks
Vivek


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kdump info request

[Mukker, Atul]

[-- Attachment #1.1: Type: text/plain, Size: 1881 bytes --]

Thanks for the reply. I guess we have pretty much nailed down device bringup sequence when loading under capture kernel. Our concern is: the capture kernel has a significant smaller memory footprint. Our RAID driver itself has a large memory requirement, some of which could fail allocation when loaded under the capture kernel.

If we could somehow determine that we are being called in context of capture kernel, we can dynamically lower driver memory requirement (at cost of lower IO throughout of-course, which is ok for this brief context).

Thanks
-Atul

-----Original Message-----
From: Vivek Goyal [mailto:vgoyal@in.ibm.com]
Sent: Tue 9/18/2007 9:53 PM
To: Mukker, Atul
Cc: vgoyal@in.ibm.com; Kexec Mailing List
Subject: Re: kdump info request
 
On Tue, Sep 18, 2007 at 03:13:42PM -0600, Mukker, Atul wrote:
> Hello Vivek, Hari:
> 
>  
> 
> Excuse me for contacting you direct, but seems like you 2 can point me
> to a right direction for a kdump question we have.
> 
>  
> 
> We are trying to make sure our RAID driver works ok when kernel is
> loaded with kdump. Is there a way for driver to detect this condition;
> that is, current kernel is running with kdump. We need this information
> so we can scale down certain operations in the driver.
> 

Hi Atul,

What do you mean by detecting if current kernel is running with kdump? Do 
you mean that you want to know the moment somebody loads a capture kernel
by kexec -p and driver will change some of its behaviour?

I think that's not the right way to go about. Explain the issue
a little bit in detail.

Generally drivers run into issues while initializing in second kernel and
one of the way to handle it is reset the device before going further with
initialization. I am hoping your RAID controller provides some kind of
reset mechanism from software.

Thanks
Vivek



[-- Attachment #1.2: Type: text/html, Size: 2520 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump info request

[Vivek Goyal]

On Tue, Sep 18, 2007 at 10:04:21PM -0600, Mukker, Atul wrote:
> Thanks for the reply. I guess we have pretty much nailed down device bringup sequence when loading under capture kernel. Our concern is: the capture kernel has a significant smaller memory footprint. Our RAID driver itself has a large memory requirement, some of which could fail allocation when loaded under the capture kernel.
> 
> If we could somehow determine that we are being called in context of capture kernel, we can dynamically lower driver memory requirement (at cost of lower IO throughout of-course, which is ok for this brief context).

You can parse the command line and look for presence of elfcorehdr= option.
This is internally appended to command line by kexec tools to tell capture
kernel the address of ELF core headers.

What's the memory allocation requirement of current RAID driver? How much
memory you are reserving for capture kernel? Are you already seeing the
memory allocation failure?

I feel until and unless memory requirements are huge, we should not
compromise with IO throughput. Capability to save the dump to disk as fast
as possible to reduce the down time is also an important consideration.

Thanks
Vivek

> 
> Thanks
> -Atul
> 
> -----Original Message-----
> From: Vivek Goyal [mailto:vgoyal@in.ibm.com]
> Sent: Tue 9/18/2007 9:53 PM
> To: Mukker, Atul
> Cc: vgoyal@in.ibm.com; Kexec Mailing List
> Subject: Re: kdump info request
>  
> On Tue, Sep 18, 2007 at 03:13:42PM -0600, Mukker, Atul wrote:
> > Hello Vivek, Hari:
> > 
> >  
> > 
> > Excuse me for contacting you direct, but seems like you 2 can point me
> > to a right direction for a kdump question we have.
> > 
> >  
> > 
> > We are trying to make sure our RAID driver works ok when kernel is
> > loaded with kdump. Is there a way for driver to detect this condition;
> > that is, current kernel is running with kdump. We need this information
> > so we can scale down certain operations in the driver.
> > 
> 
> Hi Atul,
> 
> What do you mean by detecting if current kernel is running with kdump? Do 
> you mean that you want to know the moment somebody loads a capture kernel
> by kexec -p and driver will change some of its behaviour?
> 
> I think that's not the right way to go about. Explain the issue
> a little bit in detail.
> 
> Generally drivers run into issues while initializing in second kernel and
> one of the way to handle it is reset the device before going further with
> initialization. I am hoping your RAID controller provides some kind of
> reset mechanism from software.
> 
> Thanks
> Vivek
> 
> 

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kdump info request

[Mukker, Atul]

Please see me response embedded below...

> Thanks for the reply. I guess we have pretty much nailed down device
bringup sequence when loading under capture kernel. Our concern is: the
capture kernel has a significant smaller memory footprint. Our RAID
driver itself has a large memory requirement, some of which could fail
allocation when loaded under the capture kernel.
> 
> If we could somehow determine that we are being called in context of
capture kernel, we can dynamically lower driver memory requirement (at
cost of lower IO throughout of-course, which is ok for this brief
context).

You can parse the command line and look for presence of elfcorehdr=
option.
This is internally appended to command line by kexec tools to tell
capture
kernel the address of ELF core headers.


[AM] Is this a standard way? Doesn't look like one. According to
kernel-parameters.txt, kexec would "generally" pass this option to
kernel command line. Can we look at "struct resource crashk_res" and
check if start and end member have different value, which indicates
capture kernel?

What's the memory allocation requirement of current RAID driver? How
much
memory you are reserving for capture kernel? Are you already seeing the
memory allocation failure?

[AM] Our normal runtime memory is about 20MB. For the test beds, we use
"crashkernel=192M@16M". We have not yet seen the allocation failure but
we would like to build the fallback mechanism if it does fail under
capture kernel. Only if we are not able to get the normal runtime
memory, we plan to switch to a lower memory model.

I feel until and unless memory requirements are huge, we should not
compromise with IO throughput. Capability to save the dump to disk as
fast
as possible to reduce the down time is also an important consideration.

[AM] We believe our normal runtime memory requirement is significant.
Also, even with the lower memory, there would not be a noticeable dump
time difference since lot of memory is for supporting multiple
outstanding commands in driver's raid core and other raid operations,
which will not be running under capture kernel. Thanks again for your
feedback.

Thanks
Vivek

> 
> Thanks
> -Atul
> 
> -----Original Message-----
> From: Vivek Goyal [mailto:vgoyal@in.ibm.com]
> Sent: Tue 9/18/2007 9:53 PM
> To: Mukker, Atul
> Cc: vgoyal@in.ibm.com; Kexec Mailing List
> Subject: Re: kdump info request
>  
> On Tue, Sep 18, 2007 at 03:13:42PM -0600, Mukker, Atul wrote:
> > Hello Vivek, Hari:
> > 
> >  
> > 
> > Excuse me for contacting you direct, but seems like you 2 can point
me
> > to a right direction for a kdump question we have.
> > 
> >  
> > 
> > We are trying to make sure our RAID driver works ok when kernel is
> > loaded with kdump. Is there a way for driver to detect this
condition;
> > that is, current kernel is running with kdump. We need this
information
> > so we can scale down certain operations in the driver.
> > 
> 
> Hi Atul,
> 
> What do you mean by detecting if current kernel is running with kdump?
Do 
> you mean that you want to know the moment somebody loads a capture
kernel
> by kexec -p and driver will change some of its behaviour?
> 
> I think that's not the right way to go about. Explain the issue
> a little bit in detail.
> 
> Generally drivers run into issues while initializing in second kernel
and
> one of the way to handle it is reset the device before going further
with
> initialization. I am hoping your RAID controller provides some kind of
> reset mechanism from software.
> 
> Thanks
> Vivek
> 
> 

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump info request

[Vivek Goyal]

On Wed, Sep 19, 2007 at 07:26:19AM -0600, Mukker, Atul wrote:
[..]
> > 
> > If we could somehow determine that we are being called in context of
> capture kernel, we can dynamically lower driver memory requirement (at
> cost of lower IO throughout of-course, which is ok for this brief
> context).
> 
> You can parse the command line and look for presence of elfcorehdr=
> option.
> This is internally appended to command line by kexec tools to tell
> capture
> kernel the address of ELF core headers.
> 
> 
> [AM] Is this a standard way? Doesn't look like one. According to
> kernel-parameters.txt, kexec would "generally" pass this option to
> kernel command line. Can we look at "struct resource crashk_res" and
> check if start and end member have different value, which indicates
> capture kernel?
> 

Well, nobody else so far has had such requirements so can't say if this
is standard way. But this is the best way I can think of so far.

Using crashk_res will not work. Not all users will use kdump and will not
reserve any memory for capture kernel. In that case crashk_res will be 
zero for start and end and you don't want to trim down the functionality
of your driver.

> What's the memory allocation requirement of current RAID driver? How
> much
> memory you are reserving for capture kernel? Are you already seeing the
> memory allocation failure?
> 
> [AM] Our normal runtime memory is about 20MB. For the test beds, we use
> "crashkernel=192M@16M". We have not yet seen the allocation failure but
> we would like to build the fallback mechanism if it does fail under
> capture kernel. Only if we are not able to get the normal runtime
> memory, we plan to switch to a lower memory model.
> 

20MB is huge. I agree that it is a good idea to bring it down for capture
kernel if performance is not significantly impacted.

> I feel until and unless memory requirements are huge, we should not
> compromise with IO throughput. Capability to save the dump to disk as
> fast
> as possible to reduce the down time is also an important consideration.
> 
> [AM] We believe our normal runtime memory requirement is significant.
> Also, even with the lower memory, there would not be a noticeable dump
> time difference since lot of memory is for supporting multiple
> outstanding commands in driver's raid core and other raid operations,
> which will not be running under capture kernel. Thanks again for your
> feedback.
> 

Makes sense.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kdump info request

[Mukker, Atul]

One more question, and hopefully I will not bug you further on this :-)

How exactly do you parse the kernel parameters? I thought it would be
plain simple, but seems like the command line string is not available to
SCSI driver like ours, or I am missing something?

Thanks
-Atul 

-----Original Message-----
From: Vivek Goyal [mailto:vgoyal@in.ibm.com] 
Sent: Friday, September 21, 2007 12:15 AM
To: Mukker, Atul
Cc: Kexec Mailing List; Moore, Eric
Subject: Re: kdump info request

On Wed, Sep 19, 2007 at 07:26:19AM -0600, Mukker, Atul wrote:
[..]
> > 
> > If we could somehow determine that we are being called in context of
> capture kernel, we can dynamically lower driver memory requirement (at
> cost of lower IO throughout of-course, which is ok for this brief
> context).
> 
> You can parse the command line and look for presence of elfcorehdr=
> option.
> This is internally appended to command line by kexec tools to tell
> capture
> kernel the address of ELF core headers.
> 
> 
> [AM] Is this a standard way? Doesn't look like one. According to
> kernel-parameters.txt, kexec would "generally" pass this option to
> kernel command line. Can we look at "struct resource crashk_res" and
> check if start and end member have different value, which indicates
> capture kernel?
> 

Well, nobody else so far has had such requirements so can't say if this
is standard way. But this is the best way I can think of so far.

Using crashk_res will not work. Not all users will use kdump and will
not
reserve any memory for capture kernel. In that case crashk_res will be 
zero for start and end and you don't want to trim down the functionality
of your driver.

> What's the memory allocation requirement of current RAID driver? How
> much
> memory you are reserving for capture kernel? Are you already seeing
the
> memory allocation failure?
> 
> [AM] Our normal runtime memory is about 20MB. For the test beds, we
use
> "crashkernel=192M@16M". We have not yet seen the allocation failure
but
> we would like to build the fallback mechanism if it does fail under
> capture kernel. Only if we are not able to get the normal runtime
> memory, we plan to switch to a lower memory model.
> 

20MB is huge. I agree that it is a good idea to bring it down for
capture
kernel if performance is not significantly impacted.

> I feel until and unless memory requirements are huge, we should not
> compromise with IO throughput. Capability to save the dump to disk as
> fast
> as possible to reduce the down time is also an important
consideration.
> 
> [AM] We believe our normal runtime memory requirement is significant.
> Also, even with the lower memory, there would not be a noticeable dump
> time difference since lot of memory is for supporting multiple
> outstanding commands in driver's raid core and other raid operations,
> which will not be running under capture kernel. Thanks again for your
> feedback.
> 

Makes sense.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

kdump info request

[Randy Dunlap]

On Fri, 21 Sep 2007 06:48:01 -0600 Mukker, Atul wrote:

> One more question, and hopefully I will not bug you further on this :-)
> 
> How exactly do you parse the kernel parameters? I thought it would be
> plain simple, but seems like the command line string is not available to
> SCSI driver like ours, or I am missing something?

#include <linux/init.h>  // for extern of 'saved_command_line' pointer.

and use calls to any functions in lib/cmdline.c or write your
own functions.  Should be fairly simple to scan for a fixed string
of "elfcorehdr=".
You don't care about the variable parameters.. or do you?


> Thanks
> -Atul 
> 
> -----Original Message-----
> From: Vivek Goyal [mailto:vgoyal at in.ibm.com] 
> Sent: Friday, September 21, 2007 12:15 AM
> To: Mukker, Atul
> Cc: Kexec Mailing List; Moore, Eric
> Subject: Re: kdump info request
> 
> On Wed, Sep 19, 2007 at 07:26:19AM -0600, Mukker, Atul wrote:
> [..]
> > > 
> > > If we could somehow determine that we are being called in context of
> > capture kernel, we can dynamically lower driver memory requirement (at
> > cost of lower IO throughout of-course, which is ok for this brief
> > context).
> > 
> > You can parse the command line and look for presence of elfcorehdr=
> > option.
> > This is internally appended to command line by kexec tools to tell
> > capture
> > kernel the address of ELF core headers.
> > 
> > 
> > [AM] Is this a standard way? Doesn't look like one. According to
> > kernel-parameters.txt, kexec would "generally" pass this option to
> > kernel command line. Can we look at "struct resource crashk_res" and
> > check if start and end member have different value, which indicates
> > capture kernel?
> > 
> 
> Well, nobody else so far has had such requirements so can't say if this
> is standard way. But this is the best way I can think of so far.
> 
> Using crashk_res will not work. Not all users will use kdump and will
> not
> reserve any memory for capture kernel. In that case crashk_res will be 
> zero for start and end and you don't want to trim down the functionality
> of your driver.
> 
> > What's the memory allocation requirement of current RAID driver? How
> > much
> > memory you are reserving for capture kernel? Are you already seeing
> the
> > memory allocation failure?
> > 
> > [AM] Our normal runtime memory is about 20MB. For the test beds, we
> use
> > "crashkernel=192M at 16M". We have not yet seen the allocation failure
> but
> > we would like to build the fallback mechanism if it does fail under
> > capture kernel. Only if we are not able to get the normal runtime
> > memory, we plan to switch to a lower memory model.
> > 
> 
> 20MB is huge. I agree that it is a good idea to bring it down for
> capture
> kernel if performance is not significantly impacted.
> 
> > I feel until and unless memory requirements are huge, we should not
> > compromise with IO throughput. Capability to save the dump to disk as
> > fast
> > as possible to reduce the down time is also an important
> consideration.
> > 
> > [AM] We believe our normal runtime memory requirement is significant.
> > Also, even with the lower memory, there would not be a noticeable dump
> > time difference since lot of memory is for supporting multiple
> > outstanding commands in driver's raid core and other raid operations,
> > which will not be running under capture kernel. Thanks again for your
> > feedback.
> > 
> 
> Makes sense.
> 
> Thanks
> Vivek
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

RE: kdump info request

[Mukker, Atul]

Hello Randy,

I tried this today but did not succeed :-( Can you please see the logs
appended below and point out what I might be doing wrong? This is on a
Red Hat 5 system.

Thanks
-Atul

+++++++++++
Sample code
+++++++++++
#include <linux/init.h>
#include <linux/version.h>
#include <linux/module.h>

MODULE_AUTHOR("LSI Corporation");
MODULE_VERSION("1.0");
MODULE_DESCRIPTION("Kernel Command Line");
MODULE_LICENSE("GPL");

static int __init cline_init(void)
{
	printk("enter module:[%s]\n", saved_command_line);
	return 0;
}

static void __exit cline_exit(void)
{
	printk("exit module.\n");
}

module_init(cline_init);
module_exit(cline_exit);

++++++++
Makefile
++++++++
obj-m	+= cline.o

+++++++++
Build log
+++++++++

make: Entering directory `/usr/src/kernels/2.6.18-8.el5-i686'
  LD
/usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/built-in.o
  CC [M]  /usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.o
  Building modules, stage 2.
  MODPOST
WARNING: "saved_command_line"
[/usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.ko]
undefined!
  CC
/usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.mod.o
  LD [M]  /usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.ko
make: Leaving directory `/usr/src/kernels/2.6.18-8.el5-i686'


-----Original Message-----
From: Randy Dunlap [mailto:rdunlap@xenotime.net] 
Sent: Saturday, September 22, 2007 2:36 PM
To: Mukker, Atul
Cc: vgoyal@in.ibm.com; Moore, Eric; Kexec Mailing List
Subject: Re: kdump info request

On Fri, 21 Sep 2007 06:48:01 -0600 Mukker, Atul wrote:

> One more question, and hopefully I will not bug you further on this
:-)
> 
> How exactly do you parse the kernel parameters? I thought it would be
> plain simple, but seems like the command line string is not available
to
> SCSI driver like ours, or I am missing something?

#include <linux/init.h>  // for extern of 'saved_command_line' pointer.

and use calls to any functions in lib/cmdline.c or write your
own functions.  Should be fairly simple to scan for a fixed string
of "elfcorehdr=".
You don't care about the variable parameters.. or do you?


> Thanks
> -Atul 
> 
> -----Original Message-----
> From: Vivek Goyal [mailto:vgoyal@in.ibm.com] 
> Sent: Friday, September 21, 2007 12:15 AM
> To: Mukker, Atul
> Cc: Kexec Mailing List; Moore, Eric
> Subject: Re: kdump info request
> 
> On Wed, Sep 19, 2007 at 07:26:19AM -0600, Mukker, Atul wrote:
> [..]
> > > 
> > > If we could somehow determine that we are being called in context
of
> > capture kernel, we can dynamically lower driver memory requirement
(at
> > cost of lower IO throughout of-course, which is ok for this brief
> > context).
> > 
> > You can parse the command line and look for presence of elfcorehdr=
> > option.
> > This is internally appended to command line by kexec tools to tell
> > capture
> > kernel the address of ELF core headers.
> > 
> > 
> > [AM] Is this a standard way? Doesn't look like one. According to
> > kernel-parameters.txt, kexec would "generally" pass this option to
> > kernel command line. Can we look at "struct resource crashk_res" and
> > check if start and end member have different value, which indicates
> > capture kernel?
> > 
> 
> Well, nobody else so far has had such requirements so can't say if
this
> is standard way. But this is the best way I can think of so far.
> 
> Using crashk_res will not work. Not all users will use kdump and will
> not
> reserve any memory for capture kernel. In that case crashk_res will be

> zero for start and end and you don't want to trim down the
functionality
> of your driver.
> 
> > What's the memory allocation requirement of current RAID driver? How
> > much
> > memory you are reserving for capture kernel? Are you already seeing
> the
> > memory allocation failure?
> > 
> > [AM] Our normal runtime memory is about 20MB. For the test beds, we
> use
> > "crashkernel=192M@16M". We have not yet seen the allocation failure
> but
> > we would like to build the fallback mechanism if it does fail under
> > capture kernel. Only if we are not able to get the normal runtime
> > memory, we plan to switch to a lower memory model.
> > 
> 
> 20MB is huge. I agree that it is a good idea to bring it down for
> capture
> kernel if performance is not significantly impacted.
> 
> > I feel until and unless memory requirements are huge, we should not
> > compromise with IO throughput. Capability to save the dump to disk
as
> > fast
> > as possible to reduce the down time is also an important
> consideration.
> > 
> > [AM] We believe our normal runtime memory requirement is
significant.
> > Also, even with the lower memory, there would not be a noticeable
dump
> > time difference since lot of memory is for supporting multiple
> > outstanding commands in driver's raid core and other raid
operations,
> > which will not be running under capture kernel. Thanks again for
your
> > feedback.
> > 
> 
> Makes sense.
> 
> Thanks
> Vivek
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code
***

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump info request

[Randy Dunlap]

On Mon, 1 Oct 2007 08:35:28 -0600 Mukker, Atul wrote:

> Hello Randy,
> 
> I tried this today but did not succeed :-( Can you please see the logs
> appended below and point out what I might be doing wrong? This is on a
> Red Hat 5 system.
> 
> Thanks
> -Atul

Hi Atul,

I can see the problem without looking at your module.
'saved_command_line' is only exported for modules in the sparc & 
sparc64 architectures.  What kernel version(s) do you need this
for?  Is 2.6.24 and later good enough if we can get the symbol
exported in that timeframe?

Vivek, do you want to submit a patch for this and also remove these
lines:
./arch/sparc/kernel/sparc_ksyms.c:231:EXPORT_SYMBOL(saved_command_line);
./arch/sparc64/kernel/sparc64_ksyms.c:250:EXPORT_SYMBOL(saved_command_line);

or should I attempt it?


> +++++++++++
> Sample code
> +++++++++++
> #include <linux/init.h>
> #include <linux/version.h>
> #include <linux/module.h>
> 
> MODULE_AUTHOR("LSI Corporation");
> MODULE_VERSION("1.0");
> MODULE_DESCRIPTION("Kernel Command Line");
> MODULE_LICENSE("GPL");
> 
> static int __init cline_init(void)
> {
> 	printk("enter module:[%s]\n", saved_command_line);
> 	return 0;
> }
> 
> static void __exit cline_exit(void)
> {
> 	printk("exit module.\n");
> }
> 
> module_init(cline_init);
> module_exit(cline_exit);
> 
> ++++++++
> Makefile
> ++++++++
> obj-m	+= cline.o
> 
> +++++++++
> Build log
> +++++++++
> 
> make: Entering directory `/usr/src/kernels/2.6.18-8.el5-i686'
>   LD
> /usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/built-in.o
>   CC [M]  /usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.o
>   Building modules, stage 2.
>   MODPOST
> WARNING: "saved_command_line"
> [/usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.ko]
> undefined!
>   CC
> /usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.mod.o
>   LD [M]  /usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.ko
> make: Leaving directory `/usr/src/kernels/2.6.18-8.el5-i686'
> 
> 
> -----Original Message-----
> From: Randy Dunlap [mailto:rdunlap@xenotime.net] 
> Sent: Saturday, September 22, 2007 2:36 PM
> To: Mukker, Atul
> Cc: vgoyal@in.ibm.com; Moore, Eric; Kexec Mailing List
> Subject: Re: kdump info request
> 
> On Fri, 21 Sep 2007 06:48:01 -0600 Mukker, Atul wrote:
> 
> > One more question, and hopefully I will not bug you further on this
> :-)
> > 
> > How exactly do you parse the kernel parameters? I thought it would be
> > plain simple, but seems like the command line string is not available
> to
> > SCSI driver like ours, or I am missing something?
> 
> #include <linux/init.h>  // for extern of 'saved_command_line' pointer.
> 
> and use calls to any functions in lib/cmdline.c or write your
> own functions.  Should be fairly simple to scan for a fixed string
> of "elfcorehdr=".
> You don't care about the variable parameters.. or do you?
> 
> 
> > Thanks
> > -Atul 
> > 
> > -----Original Message-----
> > From: Vivek Goyal [mailto:vgoyal@in.ibm.com] 
> > Sent: Friday, September 21, 2007 12:15 AM
> > To: Mukker, Atul
> > Cc: Kexec Mailing List; Moore, Eric
> > Subject: Re: kdump info request
> > 
> > On Wed, Sep 19, 2007 at 07:26:19AM -0600, Mukker, Atul wrote:
> > [..]
> > > > 
> > > > If we could somehow determine that we are being called in context
> of
> > > capture kernel, we can dynamically lower driver memory requirement
> (at
> > > cost of lower IO throughout of-course, which is ok for this brief
> > > context).
> > > 
> > > You can parse the command line and look for presence of elfcorehdr=
> > > option.
> > > This is internally appended to command line by kexec tools to tell
> > > capture
> > > kernel the address of ELF core headers.
> > > 
> > > 
> > > [AM] Is this a standard way? Doesn't look like one. According to
> > > kernel-parameters.txt, kexec would "generally" pass this option to
> > > kernel command line. Can we look at "struct resource crashk_res" and
> > > check if start and end member have different value, which indicates
> > > capture kernel?
> > > 
> > 
> > Well, nobody else so far has had such requirements so can't say if
> this
> > is standard way. But this is the best way I can think of so far.
> > 
> > Using crashk_res will not work. Not all users will use kdump and will
> > not
> > reserve any memory for capture kernel. In that case crashk_res will be
> 
> > zero for start and end and you don't want to trim down the
> functionality
> > of your driver.
> > 
> > > What's the memory allocation requirement of current RAID driver? How
> > > much
> > > memory you are reserving for capture kernel? Are you already seeing
> > the
> > > memory allocation failure?
> > > 
> > > [AM] Our normal runtime memory is about 20MB. For the test beds, we
> > use
> > > "crashkernel=192M@16M". We have not yet seen the allocation failure
> > but
> > > we would like to build the fallback mechanism if it does fail under
> > > capture kernel. Only if we are not able to get the normal runtime
> > > memory, we plan to switch to a lower memory model.
> > > 
> > 
> > 20MB is huge. I agree that it is a good idea to bring it down for
> > capture
> > kernel if performance is not significantly impacted.
> > 
> > > I feel until and unless memory requirements are huge, we should not
> > > compromise with IO throughput. Capability to save the dump to disk
> as
> > > fast
> > > as possible to reduce the down time is also an important
> > consideration.
> > > 
> > > [AM] We believe our normal runtime memory requirement is
> significant.
> > > Also, even with the lower memory, there would not be a noticeable
> dump
> > > time difference since lot of memory is for supporting multiple
> > > outstanding commands in driver's raid core and other raid
> operations,
> > > which will not be running under capture kernel. Thanks again for
> your
> > > feedback.
> > > 
> > 
> > Makes sense.
> > 
> > Thanks
> > Vivek

---
~Randy

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kdump info request

[Mukker, Atul]

Thanks for the information and the effort.

We need to support all currently shipping products with kdump support
available (read Red Hat and SuSE) so sooner it makes into to the
upstream kernel the better it is.

So, today there is no alternative way to find out if the driver is being
loaded under kdump restrictive environment?

Thanks
-Atul

-----Original Message-----
From: Randy Dunlap [mailto:rdunlap@xenotime.net] 
Sent: Monday, October 01, 2007 11:13 AM
To: Mukker, Atul
Cc: vgoyal@in.ibm.com; Moore, Eric; Kexec Mailing List
Subject: Re: kdump info request

On Mon, 1 Oct 2007 08:35:28 -0600 Mukker, Atul wrote:

> Hello Randy,
> 
> I tried this today but did not succeed :-( Can you please see the logs
> appended below and point out what I might be doing wrong? This is on a
> Red Hat 5 system.
> 
> Thanks
> -Atul

Hi Atul,

I can see the problem without looking at your module.
'saved_command_line' is only exported for modules in the sparc & 
sparc64 architectures.  What kernel version(s) do you need this
for?  Is 2.6.24 and later good enough if we can get the symbol
exported in that timeframe?

Vivek, do you want to submit a patch for this and also remove these
lines:
./arch/sparc/kernel/sparc_ksyms.c:231:EXPORT_SYMBOL(saved_command_line);
./arch/sparc64/kernel/sparc64_ksyms.c:250:EXPORT_SYMBOL(saved_command_li
ne);

or should I attempt it?


> +++++++++++
> Sample code
> +++++++++++
> #include <linux/init.h>
> #include <linux/version.h>
> #include <linux/module.h>
> 
> MODULE_AUTHOR("LSI Corporation");
> MODULE_VERSION("1.0");
> MODULE_DESCRIPTION("Kernel Command Line");
> MODULE_LICENSE("GPL");
> 
> static int __init cline_init(void)
> {
> 	printk("enter module:[%s]\n", saved_command_line);
> 	return 0;
> }
> 
> static void __exit cline_exit(void)
> {
> 	printk("exit module.\n");
> }
> 
> module_init(cline_init);
> module_exit(cline_exit);
> 
> ++++++++
> Makefile
> ++++++++
> obj-m	+= cline.o
> 
> +++++++++
> Build log
> +++++++++
> 
> make: Entering directory `/usr/src/kernels/2.6.18-8.el5-i686'
>   LD
> /usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/built-in.o
>   CC [M]
/usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.o
>   Building modules, stage 2.
>   MODPOST
> WARNING: "saved_command_line"
> [/usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.ko]
> undefined!
>   CC
> /usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.mod.o
>   LD [M]
/usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.ko
> make: Leaving directory `/usr/src/kernels/2.6.18-8.el5-i686'
> 
> 
> -----Original Message-----
> From: Randy Dunlap [mailto:rdunlap@xenotime.net] 
> Sent: Saturday, September 22, 2007 2:36 PM
> To: Mukker, Atul
> Cc: vgoyal@in.ibm.com; Moore, Eric; Kexec Mailing List
> Subject: Re: kdump info request
> 
> On Fri, 21 Sep 2007 06:48:01 -0600 Mukker, Atul wrote:
> 
> > One more question, and hopefully I will not bug you further on this
> :-)
> > 
> > How exactly do you parse the kernel parameters? I thought it would
be
> > plain simple, but seems like the command line string is not
available
> to
> > SCSI driver like ours, or I am missing something?
> 
> #include <linux/init.h>  // for extern of 'saved_command_line'
pointer.
> 
> and use calls to any functions in lib/cmdline.c or write your
> own functions.  Should be fairly simple to scan for a fixed string
> of "elfcorehdr=".
> You don't care about the variable parameters.. or do you?
> 
> 
> > Thanks
> > -Atul 
> > 
> > -----Original Message-----
> > From: Vivek Goyal [mailto:vgoyal@in.ibm.com] 
> > Sent: Friday, September 21, 2007 12:15 AM
> > To: Mukker, Atul
> > Cc: Kexec Mailing List; Moore, Eric
> > Subject: Re: kdump info request
> > 
> > On Wed, Sep 19, 2007 at 07:26:19AM -0600, Mukker, Atul wrote:
> > [..]
> > > > 
> > > > If we could somehow determine that we are being called in
context
> of
> > > capture kernel, we can dynamically lower driver memory requirement
> (at
> > > cost of lower IO throughout of-course, which is ok for this brief
> > > context).
> > > 
> > > You can parse the command line and look for presence of
elfcorehdr=
> > > option.
> > > This is internally appended to command line by kexec tools to tell
> > > capture
> > > kernel the address of ELF core headers.
> > > 
> > > 
> > > [AM] Is this a standard way? Doesn't look like one. According to
> > > kernel-parameters.txt, kexec would "generally" pass this option to
> > > kernel command line. Can we look at "struct resource crashk_res"
and
> > > check if start and end member have different value, which
indicates
> > > capture kernel?
> > > 
> > 
> > Well, nobody else so far has had such requirements so can't say if
> this
> > is standard way. But this is the best way I can think of so far.
> > 
> > Using crashk_res will not work. Not all users will use kdump and
will
> > not
> > reserve any memory for capture kernel. In that case crashk_res will
be
> 
> > zero for start and end and you don't want to trim down the
> functionality
> > of your driver.
> > 
> > > What's the memory allocation requirement of current RAID driver?
How
> > > much
> > > memory you are reserving for capture kernel? Are you already
seeing
> > the
> > > memory allocation failure?
> > > 
> > > [AM] Our normal runtime memory is about 20MB. For the test beds,
we
> > use
> > > "crashkernel=192M@16M". We have not yet seen the allocation
failure
> > but
> > > we would like to build the fallback mechanism if it does fail
under
> > > capture kernel. Only if we are not able to get the normal runtime
> > > memory, we plan to switch to a lower memory model.
> > > 
> > 
> > 20MB is huge. I agree that it is a good idea to bring it down for
> > capture
> > kernel if performance is not significantly impacted.
> > 
> > > I feel until and unless memory requirements are huge, we should
not
> > > compromise with IO throughput. Capability to save the dump to disk
> as
> > > fast
> > > as possible to reduce the down time is also an important
> > consideration.
> > > 
> > > [AM] We believe our normal runtime memory requirement is
> significant.
> > > Also, even with the lower memory, there would not be a noticeable
> dump
> > > time difference since lot of memory is for supporting multiple
> > > outstanding commands in driver's raid core and other raid
> operations,
> > > which will not be running under capture kernel. Thanks again for
> your
> > > feedback.
> > > 
> > 
> > Makes sense.
> > 
> > Thanks
> > Vivek

---
~Randy

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump info request

[Randy Dunlap]

On Mon, 1 Oct 2007 09:35:04 -0600 Mukker, Atul wrote:

> Thanks for the information and the effort.
> 
> We need to support all currently shipping products with kdump support
> available (read Red Hat and SuSE) so sooner it makes into to the
> upstream kernel the better it is.
> 
> So, today there is no alternative way to find out if the driver is being
> loaded under kdump restrictive environment?
> 
> Thanks
> -Atul

I'm not the right person to answer that, but going forward, it would
be nice to have that information and it would be good to do correctly.

I think that scanning <saved_command_line> is not actually the good/right
way to do this.  It should just be a flag somewhere, and the flag should
be available in all (future) kernels (and likely easily backportable
as well, if that matters), meaning those built without kdump support.

But it's still up to the kexec developers...


> -----Original Message-----
> From: Randy Dunlap [mailto:rdunlap@xenotime.net] 
> Sent: Monday, October 01, 2007 11:13 AM
> To: Mukker, Atul
> Cc: vgoyal@in.ibm.com; Moore, Eric; Kexec Mailing List
> Subject: Re: kdump info request
> 
> On Mon, 1 Oct 2007 08:35:28 -0600 Mukker, Atul wrote:
> 
> > Hello Randy,
> > 
> > I tried this today but did not succeed :-( Can you please see the logs
> > appended below and point out what I might be doing wrong? This is on a
> > Red Hat 5 system.
> > 
> > Thanks
> > -Atul
> 
> Hi Atul,
> 
> I can see the problem without looking at your module.
> 'saved_command_line' is only exported for modules in the sparc & 
> sparc64 architectures.  What kernel version(s) do you need this
> for?  Is 2.6.24 and later good enough if we can get the symbol
> exported in that timeframe?
> 
> Vivek, do you want to submit a patch for this and also remove these
> lines:
> ./arch/sparc/kernel/sparc_ksyms.c:231:EXPORT_SYMBOL(saved_command_line);
> ./arch/sparc64/kernel/sparc64_ksyms.c:250:EXPORT_SYMBOL(saved_command_li
> ne);
> 
> or should I attempt it?
> 
> 
> > +++++++++++
> > Sample code
> > +++++++++++
> > #include <linux/init.h>
> > #include <linux/version.h>
> > #include <linux/module.h>
> > 
> > MODULE_AUTHOR("LSI Corporation");
> > MODULE_VERSION("1.0");
> > MODULE_DESCRIPTION("Kernel Command Line");
> > MODULE_LICENSE("GPL");
> > 
> > static int __init cline_init(void)
> > {
> > 	printk("enter module:[%s]\n", saved_command_line);
> > 	return 0;
> > }
> > 
> > static void __exit cline_exit(void)
> > {
> > 	printk("exit module.\n");
> > }
> > 
> > module_init(cline_init);
> > module_exit(cline_exit);
> > 
> > ++++++++
> > Makefile
> > ++++++++
> > obj-m	+= cline.o
> > 
> > +++++++++
> > Build log
> > +++++++++
> > 
> > make: Entering directory `/usr/src/kernels/2.6.18-8.el5-i686'
> >   LD
> > /usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/built-in.o
> >   CC [M]
> /usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.o
> >   Building modules, stage 2.
> >   MODPOST
> > WARNING: "saved_command_line"
> > [/usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.ko]
> > undefined!
> >   CC
> > /usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.mod.o
> >   LD [M]
> /usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.ko
> > make: Leaving directory `/usr/src/kernels/2.6.18-8.el5-i686'
> > 
> > 
> > -----Original Message-----
> > From: Randy Dunlap [mailto:rdunlap@xenotime.net] 
> > Sent: Saturday, September 22, 2007 2:36 PM
> > To: Mukker, Atul
> > Cc: vgoyal@in.ibm.com; Moore, Eric; Kexec Mailing List
> > Subject: Re: kdump info request
> > 
> > On Fri, 21 Sep 2007 06:48:01 -0600 Mukker, Atul wrote:
> > 
> > > One more question, and hopefully I will not bug you further on this
> > :-)
> > > 
> > > How exactly do you parse the kernel parameters? I thought it would
> be
> > > plain simple, but seems like the command line string is not
> available
> > to
> > > SCSI driver like ours, or I am missing something?
> > 
> > #include <linux/init.h>  // for extern of 'saved_command_line'
> pointer.
> > 
> > and use calls to any functions in lib/cmdline.c or write your
> > own functions.  Should be fairly simple to scan for a fixed string
> > of "elfcorehdr=".
> > You don't care about the variable parameters.. or do you?
> > 
> > 
> > > Thanks
> > > -Atul 
> > > 
> > > -----Original Message-----
> > > From: Vivek Goyal [mailto:vgoyal@in.ibm.com] 
> > > Sent: Friday, September 21, 2007 12:15 AM
> > > To: Mukker, Atul
> > > Cc: Kexec Mailing List; Moore, Eric
> > > Subject: Re: kdump info request
> > > 
> > > On Wed, Sep 19, 2007 at 07:26:19AM -0600, Mukker, Atul wrote:
> > > [..]
> > > > > 
> > > > > If we could somehow determine that we are being called in
> context
> > of
> > > > capture kernel, we can dynamically lower driver memory requirement
> > (at
> > > > cost of lower IO throughout of-course, which is ok for this brief
> > > > context).
> > > > 
> > > > You can parse the command line and look for presence of
> elfcorehdr=
> > > > option.
> > > > This is internally appended to command line by kexec tools to tell
> > > > capture
> > > > kernel the address of ELF core headers.
> > > > 
> > > > 
> > > > [AM] Is this a standard way? Doesn't look like one. According to
> > > > kernel-parameters.txt, kexec would "generally" pass this option to
> > > > kernel command line. Can we look at "struct resource crashk_res"
> and
> > > > check if start and end member have different value, which
> indicates
> > > > capture kernel?
> > > > 
> > > 
> > > Well, nobody else so far has had such requirements so can't say if
> > this
> > > is standard way. But this is the best way I can think of so far.
> > > 
> > > Using crashk_res will not work. Not all users will use kdump and
> will
> > > not
> > > reserve any memory for capture kernel. In that case crashk_res will
> be
> > 
> > > zero for start and end and you don't want to trim down the
> > functionality
> > > of your driver.
> > > 
> > > > What's the memory allocation requirement of current RAID driver?
> How
> > > > much
> > > > memory you are reserving for capture kernel? Are you already
> seeing
> > > the
> > > > memory allocation failure?
> > > > 
> > > > [AM] Our normal runtime memory is about 20MB. For the test beds,
> we
> > > use
> > > > "crashkernel=192M@16M". We have not yet seen the allocation
> failure
> > > but
> > > > we would like to build the fallback mechanism if it does fail
> under
> > > > capture kernel. Only if we are not able to get the normal runtime
> > > > memory, we plan to switch to a lower memory model.
> > > > 
> > > 
> > > 20MB is huge. I agree that it is a good idea to bring it down for
> > > capture
> > > kernel if performance is not significantly impacted.
> > > 
> > > > I feel until and unless memory requirements are huge, we should
> not
> > > > compromise with IO throughput. Capability to save the dump to disk
> > as
> > > > fast
> > > > as possible to reduce the down time is also an important
> > > consideration.
> > > > 
> > > > [AM] We believe our normal runtime memory requirement is
> > significant.
> > > > Also, even with the lower memory, there would not be a noticeable
> > dump
> > > > time difference since lot of memory is for supporting multiple
> > > > outstanding commands in driver's raid core and other raid
> > operations,
> > > > which will not be running under capture kernel. Thanks again for
> > your
> > > > feedback.
> > > > 
> > > 
> > > Makes sense.
> > > 
> > > Thanks
> > > Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump info request

[Vivek Goyal]

On Mon, Oct 01, 2007 at 09:31:45AM -0700, Randy Dunlap wrote:
> On Mon, 1 Oct 2007 09:35:04 -0600 Mukker, Atul wrote:
> 
> > Thanks for the information and the effort.
> > 
> > We need to support all currently shipping products with kdump support
> > available (read Red Hat and SuSE) so sooner it makes into to the
> > upstream kernel the better it is.
> > 
> > So, today there is no alternative way to find out if the driver is being
> > loaded under kdump restrictive environment?
> > 
> > Thanks
> > -Atul
> 
> I'm not the right person to answer that, but going forward, it would
> be nice to have that information and it would be good to do correctly.
> 
> I think that scanning <saved_command_line> is not actually the good/right
> way to do this.  It should just be a flag somewhere, and the flag should
> be available in all (future) kernels (and likely easily backportable
> as well, if that matters), meaning those built without kdump support.
> 
> But it's still up to the kexec developers...
> 
> 

Hi Atul/Randy,

[CCing to LKML]

Thinking more about it, looks like scanning command line is not a very good
idea.

I think we should instead look for if total available RAM in the system and
then let driver make a decision about how much memory to allocate. Pavel
already suggested it on LKML and I like the idea.

This is more generic and can be applied to kdump, kexec based hibernation and
all the future users of kexec on panic infrstrcuture which will boot a 
second kernel in restricted amount of RAM.

I am not sure what's the best way to determine the total RAM in the system
in arch independent manner. Some VM guys can tell it better. One of the ways
could be to parse /proc/iomem, the way kexec-tools does. Balbir mentioned
that traverse through the nodes and sum up present_pages. 

Any suggestions, what's the best way to determine total amount of RAM
in the system in kernel?

Right now this seems to be one odd case so this code can be inside module.
If there are more users of it then we can probably create a flag inside
kernel and export it.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump info request

[Vivek Goyal]

On Mon, Oct 01, 2007 at 09:31:45AM -0700, Randy Dunlap wrote:
> On Mon, 1 Oct 2007 09:35:04 -0600 Mukker, Atul wrote:
> 
> > Thanks for the information and the effort.
> > 
> > We need to support all currently shipping products with kdump support
> > available (read Red Hat and SuSE) so sooner it makes into to the
> > upstream kernel the better it is.
> > 
> > So, today there is no alternative way to find out if the driver is being
> > loaded under kdump restrictive environment?
> > 
> > Thanks
> > -Atul
> 
> I'm not the right person to answer that, but going forward, it would
> be nice to have that information and it would be good to do correctly.
> 
> I think that scanning <saved_command_line> is not actually the good/right
> way to do this.  It should just be a flag somewhere, and the flag should
> be available in all (future) kernels (and likely easily backportable
> as well, if that matters), meaning those built without kdump support.
> 
> But it's still up to the kexec developers...
> 
> 

Hi Atul/Randy,

[CCing to LKML]

Thinking more about it, looks like scanning command line is not a very good
idea.

I think we should instead look for if total available RAM in the system and
then let driver make a decision about how much memory to allocate. Pavel
already suggested it on LKML and I like the idea.

This is more generic and can be applied to kdump, kexec based hibernation and
all the future users of kexec on panic infrstrcuture which will boot a 
second kernel in restricted amount of RAM.

I am not sure what's the best way to determine the total RAM in the system
in arch independent manner. Some VM guys can tell it better. One of the ways
could be to parse /proc/iomem, the way kexec-tools does. Balbir mentioned
that traverse through the nodes and sum up present_pages. 

Any suggestions, what's the best way to determine total amount of RAM
in the system in kernel?

Right now this seems to be one odd case so this code can be inside module.
If there are more users of it then we can probably create a flag inside
kernel and export it.

Thanks
Vivek

Re: kdump info request

[Mukker, Atul]

[-- Attachment #1.1: Type: text/plain, Size: 4089 bytes --]

Will try.

Thanks
Atul


----- Original Message -----
From: Randy Dunlap <rdunlap@xenotime.net>
To: Mukker, Atul
Cc: vgoyal@in.ibm.com <vgoyal@in.ibm.com>; Moore, Eric; Kexec Mailing List <kexec@lists.infradead.org>
Sent: Sat Sep 22 12:35:53 2007
Subject: Re: kdump info request

On Fri, 21 Sep 2007 06:48:01 -0600 Mukker, Atul wrote:

> One more question, and hopefully I will not bug you further on this :-)
> 
> How exactly do you parse the kernel parameters? I thought it would be
> plain simple, but seems like the command line string is not available to
> SCSI driver like ours, or I am missing something?

#include <linux/init.h>  // for extern of 'saved_command_line' pointer.

and use calls to any functions in lib/cmdline.c or write your
own functions.  Should be fairly simple to scan for a fixed string
of "elfcorehdr=".
You don't care about the variable parameters.. or do you?


> Thanks
> -Atul 
> 
> -----Original Message-----
> From: Vivek Goyal [mailto:vgoyal@in.ibm.com] 
> Sent: Friday, September 21, 2007 12:15 AM
> To: Mukker, Atul
> Cc: Kexec Mailing List; Moore, Eric
> Subject: Re: kdump info request
> 
> On Wed, Sep 19, 2007 at 07:26:19AM -0600, Mukker, Atul wrote:
> [..]
> > > 
> > > If we could somehow determine that we are being called in context of
> > capture kernel, we can dynamically lower driver memory requirement (at
> > cost of lower IO throughout of-course, which is ok for this brief
> > context).
> > 
> > You can parse the command line and look for presence of elfcorehdr=
> > option.
> > This is internally appended to command line by kexec tools to tell
> > capture
> > kernel the address of ELF core headers.
> > 
> > 
> > [AM] Is this a standard way? Doesn't look like one. According to
> > kernel-parameters.txt, kexec would "generally" pass this option to
> > kernel command line. Can we look at "struct resource crashk_res" and
> > check if start and end member have different value, which indicates
> > capture kernel?
> > 
> 
> Well, nobody else so far has had such requirements so can't say if this
> is standard way. But this is the best way I can think of so far.
> 
> Using crashk_res will not work. Not all users will use kdump and will
> not
> reserve any memory for capture kernel. In that case crashk_res will be 
> zero for start and end and you don't want to trim down the functionality
> of your driver.
> 
> > What's the memory allocation requirement of current RAID driver? How
> > much
> > memory you are reserving for capture kernel? Are you already seeing
> the
> > memory allocation failure?
> > 
> > [AM] Our normal runtime memory is about 20MB. For the test beds, we
> use
> > "crashkernel=192M@16M". We have not yet seen the allocation failure
> but
> > we would like to build the fallback mechanism if it does fail under
> > capture kernel. Only if we are not able to get the normal runtime
> > memory, we plan to switch to a lower memory model.
> > 
> 
> 20MB is huge. I agree that it is a good idea to bring it down for
> capture
> kernel if performance is not significantly impacted.
> 
> > I feel until and unless memory requirements are huge, we should not
> > compromise with IO throughput. Capability to save the dump to disk as
> > fast
> > as possible to reduce the down time is also an important
> consideration.
> > 
> > [AM] We believe our normal runtime memory requirement is significant.
> > Also, even with the lower memory, there would not be a noticeable dump
> > time difference since lot of memory is for supporting multiple
> > outstanding commands in driver's raid core and other raid operations,
> > which will not be running under capture kernel. Thanks again for your
> > feedback.
> > 
> 
> Makes sense.
> 
> Thanks
> Vivek
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

[-- Attachment #1.2: Type: text/html, Size: 5473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec