linux-kernel - Re: [PATCH] kexec: use Crash kernel for Crash kernel low

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 2 Apr 2013 09:30:19 -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 01:47:58PM -0700, H. Peter Anvin wrote:

[..]
> > 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.
> 
> At least heuristics in a script is better than telling the user "guess
> and pray".

Current heuristics are outside the kernel. That is we run tests on bunch
of machines and try to figure out what's a reasonable default amount of
reserved memory (with our kernel and with our initramfs and default
settings).

So we carry a patch in kernel which supports crashkernel=auto option.
Installer puts this option on boot loader command line during installation.

And in kernel we have hardcoded the per arch memory reservation requirements
and we update these limits if something significant changes either in
kernel or in user space in terms of memory consumption.

Initially we had tried to guess second kernel's memory usage based on
first kernel's memory usage, but that did not work. There were many
factors.

- First kernel brought up all the cpus and that inreases the memory
  consumption. While we bring up only one cpu (with nr_cpus=1) in
  kdump kernel.

- We disable memory cgroup controller while first kernel has it enabled
  and that can change memory requirement significantly on large machines.

- We don't bring up all the devices in second kernel while we do in
  first kernel. So module memory usage can be significantly higher in
  first kernel.

So it has been very tricky to come up with some kind of guidelines in
an automated manner. 

But I am more than willing to look into it if there are more ideas on
how one can go about figuring out how much memory to reserve and where
to reserve.

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/