linux-kernel - Re: crash dump memory reservation regression

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]

Message-ID: <20120313142624.GE29169@redhat.com>
Date:	Tue, 13 Mar 2012 10:26:24 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	CAI Qian <caiqian@...hat.com>, Takashi Iwai <tiwai@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org
Subject: Re: crash dump memory reservation regression

On Mon, Mar 12, 2012 at 10:31:21PM -0700, Yinghai Lu wrote:

[..]
> 3.  fix kdump, and make kdump could take two ranges, one is small
> segment below 512M, other part could be more than 4G.

I will prefer to avoid supporting split memory range for kdump memory.
This will make the kdump solution complicated and we might not have
much to gain.

In general focus is to reserve as less a memory as possible for kdump
kernel. Currently for x86, we reserve 128M adhoc block by default and
scale it up by 64MB per 1TB of physical RAM (dump filtering utility
requires 2bits of memory per 4K physical page).

So as long as we can reserve till 512MB of kdump memory, that should allow
us to support up to 6TB of systems with dump filtering. Hopefully that is
sufficient for quite some time and we don't have to take the path of
supporting non-contiguous memory for kdump.

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/