[PATCH v2 1/2] fadump: reduce memory consumption for capture kernel

Hari Bathini hbathini at linux.vnet.ibm.com
Mon Apr 24 22:56:37 AEST 2017


Hi Michal.

On Monday 24 April 2017 03:54 PM, Michal Suchánek wrote:
> On Fri, 21 Apr 2017 00:19:55 +0530
> Hari Bathini <hbathini at linux.vnet.ibm.com> wrote:
>
>> On Wednesday 19 April 2017 07:38 PM, Michal Suchánek wrote:
>>> On Wed, 19 Apr 2017 14:19:47 +1000
>>> Michael Ellerman <mpe at ellerman.id.au> wrote:
>>>   
>>>> Michal Suchánek <msuchanek at suse.de> writes:
>>>>> On Mon, 17 Apr 2017 20:43:02 +0530
>>>>> Hari Bathini <hbathini at linux.vnet.ibm.com> wrote:
>>>>>> On Friday 14 April 2017 01:28 AM, Michal Suchánek wrote:
>>>>>>> more (optional) properties cannot be added?
>>>>>> Kernel change seems simple over f/w enhancement..
>>>>> That certainly looks so when you are a kernel developer and can
>>>>> implement the change yourself compared to convincing some firmware
>>>>> developer that this feature makes sense.
>>>>>
>>>>> On the other hand, the proposed kernel-only solution introduces
>>>>> requirement that the maintainer does not like.
>>>>>
>>>>> For the platform as a whole does it make more sense to add a hack
>>>>> to the kernel or does it make sense to enhance the firmware to
>>>>> provide more options for firmware-assisted dump?
>>>> Unfortunately it doesn't really matter, because there is firmware
>>>> out there that implements the current behaviour and will never be
>>>> updated. So we have to work with what's there.
>>>>   
>>> It's not that with the existing firmware fadump does not work. It
>>> just uses more memory than needed. So if new firmware revision
>>> allows more flexibility it will work for people with updated
>>> firmware and people with outdated firmware will get the current
>>> behavior.
>>>
>>> The memory saving is only significant for big systems so only people
>>> running those will get significant improvement from the updated
>>> firmware.
>>>   
>>
>> Hi Michal,
>>
>> With the fadump_append= approach I posted in this response thread,
>> additional parameters are enforced when fadump is active. If f/w
>> supports appending additional parameters, it has to update
>> chosen/bootargs whenever fadump is active. Almost the same thing
>> except the dirty job is now done by f/w? Hence I thought
>> fadump_append= kernel parameter approach is simple and lesser of the
>> two evils? Am i missing something here..
>>
> The firmware already has to set the parameter by which the kernel can
> tell it is a fadump kernel. Hence it already modifies the devicetree for
> fadump and you have to rely on it to do so.

Right, devicetree is modified to include new 'ibm,kernel-dump' rtas node
informing that fadump is active.

> The handover area which stores the additional parameters is reserved by
> the running kernel so now you also have to rely on the running kernel,
> the running kernel and fadum kernel having the same idea about the
> location of handover area, the crashing kernel not randomly overwriting
> the handover area, etc.
>
> In short it is additional potential for trouble which can be avoided.
>
> I don't know if the firmware does protect the fadump reserved area and
> devicetree from being randomly overwritten by the crashing kernel but
> it is in the position to do so if desired. The handover area is
> controlled by the crashing kernel and cannot have this guarantee.
>
>

I thinks there is a mixup here..
I am no longer batting for handover area approach but
"fadump_append=" approach (suggested by Michael Ellerman in this thread)
where there is no need for a handover area but an additional kernel
parameter fadump_append=numa=off,nr_cpus=1.. which is a comma separated
list of parameters the user wants to enforce when fadump is active.

I was trying to say that passing additional parameters with 'fadump_append='
kernel parameter is better over f/w changing the chosen/bootargs node.


Thanks
Hari



More information about the Linuxppc-dev mailing list