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:	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ