| 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
| ||
|
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/
Powered by blists - more mailing lists