All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@in.ibm.com>
To: Randy Dunlap <rdunlap@xenotime.net>
Cc: "Mukker, Atul" <Atul.Mukker@lsi.com>,
	balbir@in.ibm.com, Kexec Mailing List <kexec@lists.infradead.org>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Pavel Machek <pavel@ucw.cz>, "Moore, Eric" <Eric.Moore@lsi.com>
Subject: Re: kdump info request
Date: Wed, 3 Oct 2007 09:45:45 +0530	[thread overview]
Message-ID: <20071003041545.GA5343@in.ibm.com> (raw)
In-Reply-To: <20071001093145.7205773d.rdunlap@xenotime.net>

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

WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@in.ibm.com>
To: Randy Dunlap <rdunlap@xenotime.net>
Cc: "Mukker, Atul" <Atul.Mukker@lsi.com>,
	"Moore, Eric" <Eric.Moore@lsi.com>,
	Kexec Mailing List <kexec@lists.infradead.org>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>,
	balbir@in.ibm.com, Pavel Machek <pavel@ucw.cz>
Subject: Re: kdump info request
Date: Wed, 3 Oct 2007 09:45:45 +0530	[thread overview]
Message-ID: <20071003041545.GA5343@in.ibm.com> (raw)
In-Reply-To: <20071001093145.7205773d.rdunlap@xenotime.net>

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

  reply	other threads:[~2007-10-03  4:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9738BCBE884FDB42801FAD8A7769C26501B2C43C@NAMAIL1.ad.lsil.com>
2007-09-19  3:53 ` kdump info request Vivek Goyal
2007-09-19  4:04   ` Mukker, Atul
2007-09-19  4:28     ` Vivek Goyal
2007-09-19 13:26       ` Mukker, Atul
2007-09-21  4:15         ` Vivek Goyal
2007-09-21 12:48           ` Mukker, Atul
2007-09-22 18:35             ` Randy Dunlap
2007-10-01 14:35               ` Mukker, Atul
2007-10-01 15:13                 ` Randy Dunlap
2007-10-01 15:35                   ` Mukker, Atul
2007-10-01 16:31                     ` Randy Dunlap
2007-10-03  4:15                       ` Vivek Goyal [this message]
2007-10-03  4:15                         ` Vivek Goyal
2007-09-22 20:01 Mukker, Atul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071003041545.GA5343@in.ibm.com \
    --to=vgoyal@in.ibm.com \
    --cc=Atul.Mukker@lsi.com \
    --cc=Eric.Moore@lsi.com \
    --cc=balbir@in.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rdunlap@xenotime.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.