Will try. Thanks Atul ----- Original Message ----- From: Randy Dunlap <rdunlap@xxxxxxxxxxxx> To: Mukker, Atul Cc: vgoyal at in.ibm.com <vgoyal at in.ibm.com>; Moore, Eric; Kexec Mailing List <kexec at 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 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 *** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.infradead.org/pipermail/kexec/attachments/20070922/886711de/attachment.html
