linux-kernel - Re: [RFC v2 0/2] Early use of boot service memory

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: <20131122022957.GE31921@redhat.com>
Date:	Thu, 21 Nov 2013 21:29:57 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	jerry.hoemann@...com, "H. Peter Anvin" <hpa@...or.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Rob Landley <rob@...dley.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Matt Fleming <matt.fleming@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Borislav Petkov <bp@...e.de>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-efi@...r.kernel.org, Pekka Enberg <penberg@...nel.org>,
	Ingo Molnar <mingo.kernel.org@...il.com>,
	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>,
	Atsushi Kumagai <kumagai-atsushi@....nes.nec.co.jp>
Subject: Re: [RFC v2 0/2] Early use of boot service memory

[..]
> > makedumpfile going to cyclic buffer has helped out greatly, but on
> > our new systems we're still looking at 512 MB crash kernels.
> 
> I tried 6TiB system/16 PCIE cards, kdump on RHEL 6.5 beta still does not work.
> still get OOM.

What crashkernel= option you are using?

Interesting. So something is consuming lot of memory. How about setting
"debug_mem_level 1" in /etc/kdump.conf and regenerate initrd and retry.
This time it should output some memory usage info at various points 
during boot and that can give us some idea who is consuming how much
memory.

If some module are consuming lot of memory, then you can try "blacklist"
option in /etc/kdump.conf to disable those.

If it is not modules, then it will concern me because then either
kernel is consuming too much memory (which it should not) or for
some reason makedumpfile cyclic mode did not work for you properly.

While you are re-testing, how about also increasing debug message
level of makedumpfile. makedumpfile developers should be able to 
have a look at that. In /etc/kdump.conf, specify.

core_collector makedumpfile -c --message-level 31 -d 31

If message level 31 turns out to be too verbose, reduce it as per
makedumpfile man page.

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/