linux-kernel - Re: [PATCH v2] Do not reserve crashkernel high memory if crashkernel low memory reserving failed

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: <20150722011335.GA2639@dhcp-17-102.nay.redhat.com>
Date:	Wed, 22 Jul 2015 09:13:35 +0800
From:	Baoquan He <bhe@...hat.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Dave Young <dyoung@...hat.com>, tglx@...utronix.de,
	mingo@...hat.com, hpa@...or.com, bp@...e.de,
	akpm@...ux-foundation.org, jkosina@...e.cz, vgoyal@...hat.com,
	linux-kernel@...r.kernel.org, yinghai@...nel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH v2] Do not reserve crashkernel high memory if crashkernel
 low memory reserving failed

On 07/21/15 at 09:38am, Ingo Molnar wrote:
> 
> * Dave Young <dyoung@...hat.com> wrote:
> 
> > Hi, Baoquan
> > 
> > The interface was introduced by Yinghai, ccing him.
> 
> Also, why was this syntax introduced in the first place? Why should the user 
> care??

The user space tool makedumpfile default to use bitmap array to mark
all pages if they are dumpable or need be filtered out. For x86_64 the
filtering logic requires 2bits per 4K of RAM except of kdump kernel
running. Then 1G memory will cost 512K bytes, 1T costs 512M. So for
system with more than 1T physical memory user prefers crashkernel memory
resereved above 4G since memory space above 4G could be huge while
memory under 4G is very limited. So system with more than 1T physical
memory should take high memory and with a very few low memory
reservation, e.g about 100M. This is very cost-effective for those
systems where pci memory space is very precious because of many pci
devices.

I think it's more meaningful to provide a ,high/,low for those systems
which need reserve about 500M~1G crashkernel memory since they can be
allocated in below 4G successfully and can be allocated above 4G for
saving pci memory space. where to reserve is decided by user who knows
if they need it.

> 
> We should only have a single crashkernel option, to enable it - and everything 
> else should be figured out by the kernel, automatically.

We could provide a single crashkernel option, like
crashkernel=xxx:yyy-zzz, xxx is size, yyy-zzz is range starting and end
address. But when memory is reserved above 4G, we still need be told if
low memory is needed since some systems must have low memory, some don't
need it like systems with hardware iommu.

Thanks
Baoquan
--
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/