lkml.org 
[lkml]   [2013]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v5] x86, kdump: Set crashkernel_low automatically
From
On Wed, Mar 20, 2013 at 9:03 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Wed, Mar 20, 2013 at 08:53:29AM -0700, Yinghai Lu wrote:
>> On Wed, Mar 20, 2013 at 6:08 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
>>
>> > Have a general question about crashkernel_low. Why does it need to
>> > show up as "Crash kernel low" in /proc/iomem. Will it not be better
>> > that all memory reserved for crashkernel (whether high or low), shows
>> > as "Crash Kernel" and let kexec-tools decide whether to load kernel
>> > high or low etc.
>> >
>> > IOW, there should not be any need to differentiate between "Crash kernel"
>> > and "Crash kernel low". There are address ranges associated and looking
>> > at addresses it is obivious that certain memory is below 4G.
>>
>> yes. it is doable.
>> but
>> 1. will need to add more code to expand parse_iomem_single to handle
>> multiple "Crash kernel" in kexec-tools.
>> 2. also we already have "crashkernel_low=" in command line, so it is
>> good to keep them consistent in /proc/iomem.
>
> I think command line and /proc/iomem output are very different.
> crashkernel_low is just enforcing that reserve it below 4G and memory
> type still remains "Crash Kernel".
>
> So to me, /proc/iomem is showing ranges and memory type and both the
> memory types should be "Crash Kernel".
>
> IMHO, we should add code in kexec-tools to deal with it (multiple
> entries for memory type "Crash Kernel"), instead of especial casing
> "Crash Kernel Low". Who knows down the line we end up reserving more
> crash kernel memory which is not contiguous. Keeping all reserved
> memory of same type will help then.

ok.

Need to fix kexec-tools at first, and the drop Low in kernel.

Before v3.9 and kexec-tools 2.0.4?

Thanks

Yinghai


\
 
 \ /
  Last update: 2013-03-20 18:01    [W:0.093 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site