linux-kernel - Re: [Patch 4/7] ia64: implement crashkernel=auto

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] [day] [month] [year] [list]

Message-ID: <4A7F8DB2.5040501@redhat.com>
Date:	Mon, 10 Aug 2009 11:02:10 +0800
From:	Amerigo Wang <amwang@...hat.com>
To:	Bernhard Walle <bernhard.walle@....de>
CC:	linux-kernel@...r.kernel.org, tony.luck@...el.com,
	linux-ia64@...r.kernel.org, Neil Horman <nhorman@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andi Kleen <andi@...stfloor.org>, akpm@...ux-foundation.org,
	Fenghua Yu <fenghua.yu@...el.com>, Ingo Molnar <mingo@...e.hu>,
	Anton Vorontsov <avorontsov@...mvista.com>
Subject: Re: [Patch 4/7] ia64: implement crashkernel=auto

Bernhard Walle wrote:
> Amerigo Wang schrieb:
>   
>>  
>> +#ifdef CONFIG_KEXEC_AUTO_RESERVE
>> +#ifdef KEXEC_AUTO_RESERVED_SIZE
>> +#undef KEXEC_AUTO_RESERVED_SIZE
>> +#endif
>> +#define KEXEC_AUTO_RESERVED_SIZE (1ULL<<28) /* 256M */
>> +#include <asm-generic/kexec.h>
>> +#endif
>> +
>>  extern struct kimage *ia64_kimage;
>>     
>
> IMO that's way too small for practial use on IA64 systems.
>
> For SLES11, which is based on Linux 2.6.28 IIRC, we use following memory
> size values in the YaST2 kdump module which configures the crashkernel
> parameter (this is YCP syntax, but I think everybody understands it):
>
>   
>> // bnc #446480 - Fine-tune kdump memory proposal
>> if ((Arch::ia64()) && (total_memory >= 1024))
>> {
>>     integer total_memory_gigabyte = total_memory/1024;
>>     if ((total_memory_gigabyte >= 1) && (total_memory_gigabyte <12))
>>         alocated_memory = "256";
>>     else if ((total_memory_gigabyte >= 12) && (total_memory_gigabyte <128))
>>         alocated_memory = "512";
>>     else if ((total_memory_gigabyte >= 128) && (total_memory_gigabyte <256))
>>         alocated_memory = "768";
>>     else if ((total_memory_gigabyte >= 256) && (total_memory_gigabyte <378))
>>         alocated_memory = "1024";
>>     else if ((total_memory_gigabyte >= 378) && (total_memory_gigabyte <512))
>>         alocated_memory = "1536";
>>     else if ((total_memory_gigabyte >= 512) && (total_memory_gigabyte <768))
>>         alocated_memory = "2048";
>>     else if (total_memory_gigabyte >= 768)
>>         alocated_memory = "3072";
>> }
>>     
>
> I got that assumtions from SGI (and they are known to have large IA64
> systems) and I think the values were tested.
>   

Hmm, thanks for this.

> But IMO it doesn't make sense to put such policy decisions in the
> kernel. I see no advantage for that. The average user doesn't have to
> write crashkernel parameters, they use the values that the distribution
> ships. Or do you think that an average user knows what a UUID of a file
> system is just to specify the correct root partition?
>   
The advantage is that we can provide a clever policy which can't be 
implemented with current mechanism, e.g. 32nd of phy mem, as proposed by 
Eric.


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