linux-kernel - Re: [PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM

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, 23 Oct 2013 23:11:51 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	WANG Chao <chaowang@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Pekka Enberg <penberg@...nel.org>,
	Jacob Shin <jacob.shin@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86, kdump: crashkernel=X try to reserve below 896M
 first, then try below 4G, then MAXMEM

On Mon, Oct 21, 2013 at 8:16 AM, Vivek Goyal <vgoyal@...hat.com> wrote:
> On Fri, Oct 18, 2013 at 10:45:43PM -0700, Yinghai Lu wrote:
>
>
> IIUC, you are trying to say that with new kernel old kexec-tools will fail
> at a different failure point. I don't see why that is a problem. It still
> fails.

Yes, that could cause confusion.

We already knew it would fail possible at most later, we should make
it skip allocation during first kernel booting.

>
> [..]
>> > You are not thinking about ease of use here for existing users.
>>
>> most existing user don't need to do anything. just with new kernel and
>> old kexec tools.
>>
>> those system that did not work kexec before because XM is too big, they have to
>> update kexec tools, and use ",high"
>>
>> Make it simple, less error.
>
> No, it is not that simple. Think from a distribution's perspective also.
> We have the logic to scale reserved memory based on physical memory
> present in the system. Now we are seeing bigger memory systems (which
> would not have worked in the past). We still want to retain the existing
> logic and not switch to crashkernel=x,high. One does not have to. It
> makes life simpler.

distribution should go with ",high" for 64 bit kernel and new kexec-tools.
for 32bit kernel, you still can have ",high" or not, as ",high" is ignored.


>
> Same logic working both with smaller memory systems as well as large memory
> systems. One should not have to choose a different command line because
> there is more physical RAM present in the system.

",high" is working even on smaller memory sytem.

>
>>
>> We already support above 4G, what is point for trying below 4G?
>
> Because it is not *required* to reserve memory above 4G. Because we want
> same command line to work with both small memory systems as well as
> large memory systems and we don't care whether memory is reserved below
> 4G or above 4G. What does matter though that we don't have to worry about
> switching command line option if it is large memory system.

",high" will work smaller or large memory system after you install new
kexec tools.

Again, for distribution, when new kernel is added, new kernel will all
have ",high"
and new kexec-tools get installed.

Even we want to extend crashkernel=XM, then i would like to have
it identical to crashkernel=XM,high instead.

Thanks

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