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

2017-04-25 Thread Michal Suchánek 
On Tue, 25 Apr 2017 18:43:11 +0530
Hari Bathini  wrote:

> On Monday 24 April 2017 07:30 PM, Michal Suchánek wrote:
> > On Mon, 24 Apr 2017 18:26:37 +0530
> > Hari Bathini  wrote:
> >  
> >> Hi Michal.
> >>

> >>> 
> >> 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.  
> >
> > Ok, so a fadump specific parameter was just removed in
> > 25031865553e5a2bd9b6e0a5d044952cfa2925d8 and with this we get one
> > back.  
> 
> I think you mean commit c2afb7ce9d088696427018ba2135b898058507b8
> from linux-next. If so, yes.
> 
> > If this is going to be added as an extra kernel parameter can't
> > this be passed to kdump kernel as well? Does kdump not have the same
> > restrictions?
> >  
> 
> kdump kernel is loaded with kexec and additional parameters can be 
> passed to it at the
> time of loading. But fadump kernel boots like a regular kernel
> (through f/w & bootloader,
> resetting all the h/w) except that f/w guarantees to keep the memory 
> intact. So, there is
> a need for a different approach to pass additional parameters in case
> of fadump..
> 

I see, you can pass different commandline to the kdump kernel while
loading it with kexec but fadump kernel is booted same as normal kernel
until it looks at the devicetree so the extra arguments have to be
passed always and only appended to the commandline in the fadump case.

This sounds reasonable.

Thanks

Michal

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

2017-04-25 Thread Hari Bathini 



On Monday 24 April 2017 07:30 PM, Michal Suchánek wrote:

On Mon, 24 Apr 2017 18:26:37 +0530
Hari Bathini  wrote:


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

On Wednesday 19 April 2017 07:38 PM, Michal Suchánek wrote:

On Wed, 19 Apr 2017 14:19:47 +1000
Michael Ellerman  wrote:
 

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.


Ok, so a fadump specific parameter was just removed in
25031865553e5a2bd9b6e0a5d044952cfa2925d8 and with this we get one back.


I think you mean commit c2afb7ce9d088696427018ba2135b898058507b8
from linux-next. If so, yes.


If this is going to be added as an extra kernel parameter can't this be
passed to kdump kernel as well? Does kdump not have the same
restrictions?



kdump kernel is loaded with kexec and additional parameters can be 
passed to it at the
time of loading. But fadump kernel boots like a regular kernel (through 
f/w & bootloader,
resetting all the h/w) except that f/w guarantees to keep the memory 
intact. So, there is
a need for a different approach to pass additional parameters in case of 
fadump..


Thanks
Hari

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

2017-04-24 Thread Michal Suchánek 
On Mon, 24 Apr 2017 18:26:37 +0530
Hari Bathini  wrote:

> 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  wrote:
> >  
> >> On Wednesday 19 April 2017 07:38 PM, Michal Suchánek wrote:  
> >>> On Wed, 19 Apr 2017 14:19:47 +1000
> >>> Michael Ellerman  wrote:
> >>> 

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


Ok, so a fadump specific parameter was just removed in
25031865553e5a2bd9b6e0a5d044952cfa2925d8 and with this we get one back.
If this is going to be added as an extra kernel parameter can't this be
passed to kdump kernel as well? Does kdump not have the same
restrictions?

Thanks

Michal

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

2017-04-24 Thread Hari Bathini 

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


On Wednesday 19 April 2017 07:38 PM, Michal Suchánek wrote:

On Wed, 19 Apr 2017 14:19:47 +1000
Michael Ellerman  wrote:
  

Michal Suchánek  writes:

On Mon, 17 Apr 2017 20:43:02 +0530
Hari Bathini  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

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

2017-04-24 Thread Michal Suchánek 
On Fri, 21 Apr 2017 00:19:55 +0530
Hari Bathini  wrote:

> On Wednesday 19 April 2017 07:38 PM, Michal Suchánek wrote:
> > On Wed, 19 Apr 2017 14:19:47 +1000
> > Michael Ellerman  wrote:
> >  
> >> Michal Suchánek  writes:  
> >>> On Mon, 17 Apr 2017 20:43:02 +0530
> >>> Hari Bathini  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.

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.

Thanks

Michal

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

2017-04-20 Thread Hari Bathini 



On Wednesday 19 April 2017 07:38 PM, Michal Suchánek wrote:

On Wed, 19 Apr 2017 14:19:47 +1000
Michael Ellerman  wrote:


Michal Suchánek  writes:

On Mon, 17 Apr 2017 20:43:02 +0530
Hari Bathini  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..


Thanks
Hari

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

2017-04-19 Thread Michal Suchánek 
On Wed, 19 Apr 2017 14:19:47 +1000
Michael Ellerman  wrote:

> Michal Suchánek  writes:
> > On Mon, 17 Apr 2017 20:43:02 +0530
> > Hari Bathini  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.

Thanks

Michal

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

2017-04-18 Thread Michael Ellerman 
Michal Suchánek  writes:
> On Mon, 17 Apr 2017 20:43:02 +0530
> Hari Bathini  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.

I don't think fadump_append is a hack, though it's not pretty I'll
admit.

cheers

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

2017-04-18 Thread Michal Suchánek 
On Mon, 17 Apr 2017 20:43:02 +0530
Hari Bathini  wrote:

> On Friday 14 April 2017 01:28 AM, Michal Suchánek wrote:
> > On Thu, 13 Apr 2017 01:59:13 +0530
> > Hari Bathini  wrote:
> >  
> >> On Friday 07 April 2017 07:16 PM, Michael Ellerman wrote:  
> >>> Hari Bathini  writes:  
>  On Friday 07 April 2017 07:24 AM, Michael Ellerman wrote:  
> > My preference would be that the fadump kernel "just works". If
> > it's using too much memory then the fadump kernel should do
> > whatever it needs to use less memory, eg. shrinking nr_cpu_ids
> > etc. Do we actually know *why* the fadump kernel is running out
> > of memory? Obviously large numbers of CPUs is one of the main
> > drivers (lots of stacks required). But other than that what is
> > causing the memory pressure? I would like some data on that
> > before we proceed.  
>  Almost the same amount of memory in comparison with the memory
>  required to boot the production kernel but that is unwarranted
>  for fadump (dump capture) kernel.  
> >>> That's not data! :)
> >>>
> >>> The dump kernel is booted with *much* less memory than the
> >>> production kernel (that's the whole issue!) and so it doesn't need
> >>> to create struct pages for all that memory, which means it should
> >>> need less memory.
> >>>
> >>> The vfs caches are also sized based on the available memory, so
> >>> they should also shrink in the dump kernel.
> >>>
> >>> I want some actual numbers on what's driving the memory usage.
> >>>
> >>> I tried some of these parameters to see how much memory they would
> >>> save:  
> >> Hi Michael,
> >>
> >> Tried to get data to show parameters like numa=off &
> >> cgroup_disable=memory matter too but parameter nr_cpus=1 is making
> >> parameters like numa=off, cgroup_disable=memory insignificant.
> >> Also, these parameters not using much of early memory reservations
> >> is making quantification of memory saved for each of them that
> >> much more difficult. But I would still like to argue that passing
> >> additional parameters to fadump is better than enforcing nr_cpus=1
> >> in the kernel for:
> >>
> >> a) With makedumpfile tool supporting multi-threading it would
> >> make sense to leave the choice of how many CPUs to have, to the
> >> user.
> >>
> >> b) Parameters like udev.children-max=2 can help to reduce the
> >> number of parallel executed events bringing down the memory
> >> pressure on fadump kernel (when it is booted with more than one
> >> CPU).
> >>
> >> c) Ease of maintainability is better (considering any new
> >> kernel features with some memory to save or stability to gain on
> >> disabling, possible platform supports) with append approach over
> >> enforcing these parameters
> >>in the kernel.
> >>
> >> d) It would give user the flexibility to disable unwanted
> >> kernel features in fadump kernel (numa=off,
> >> cgroup_disable=memory). For every feature enabled in the
> >> production kernel, fadump kernel will have the choice to
> >>opt out of it, provided there is such cmdline option.  
> > Hello,  
> 
> Hi Michal,
> 
> > can't the extra parameters be passed in the devicetree?  
> 
> Hmmm.. possible. Without change in f/w, this may not be guaranteed
> though.
> 
> > The docs say that the kernel can tell it's a fadump crash kernel by
> > checking the devicetree ibm,dump-kernel property. Is there any
> > reason  
> 
> This node is exported by firmware
> 
> > 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?

Thanks

Michal

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

2017-04-17 Thread Hari Bathini 



On Friday 14 April 2017 01:28 AM, Michal Suchánek wrote:

On Thu, 13 Apr 2017 01:59:13 +0530
Hari Bathini  wrote:


On Friday 07 April 2017 07:16 PM, Michael Ellerman wrote:

Hari Bathini  writes:

On Friday 07 April 2017 07:24 AM, Michael Ellerman wrote:

My preference would be that the fadump kernel "just works". If
it's using too much memory then the fadump kernel should do
whatever it needs to use less memory, eg. shrinking nr_cpu_ids
etc. Do we actually know *why* the fadump kernel is running out
of memory? Obviously large numbers of CPUs is one of the main
drivers (lots of stacks required). But other than that what is
causing the memory pressure? I would like some data on that
before we proceed.

Almost the same amount of memory in comparison with the memory
required to boot the production kernel but that is unwarranted for
fadump (dump capture) kernel.

That's not data! :)

The dump kernel is booted with *much* less memory than the
production kernel (that's the whole issue!) and so it doesn't need
to create struct pages for all that memory, which means it should
need less memory.

The vfs caches are also sized based on the available memory, so they
should also shrink in the dump kernel.

I want some actual numbers on what's driving the memory usage.

I tried some of these parameters to see how much memory they would
save:

Hi Michael,

Tried to get data to show parameters like numa=off &
cgroup_disable=memory matter too but parameter nr_cpus=1 is making
parameters like numa=off, cgroup_disable=memory insignificant. Also,
these parameters not using much of early memory reservations is
making quantification of memory saved for each of them that much more
difficult. But I would still like to argue that passing additional
parameters to fadump is better than enforcing nr_cpus=1 in the kernel
for:

a) With makedumpfile tool supporting multi-threading it would make
sense to leave the choice of how many CPUs to have, to the user.

b) Parameters like udev.children-max=2 can help to reduce the
number of parallel executed events bringing down the memory pressure
on fadump kernel (when it is booted with more than one CPU).

c) Ease of maintainability is better (considering any new kernel
features with some memory to save or stability to gain on disabling,
possible platform supports) with append approach over enforcing these
parameters
   in the kernel.

d) It would give user the flexibility to disable unwanted kernel
features in fadump kernel (numa=off, cgroup_disable=memory). For
every feature enabled in the production kernel, fadump kernel will
have the choice to
   opt out of it, provided there is such cmdline option.

Hello,


Hi Michal,


can't the extra parameters be passed in the devicetree?


Hmmm.. possible. Without change in f/w, this may not be guaranteed though.


The docs say that the kernel can tell it's a fadump crash kernel by
checking the devicetree ibm,dump-kernel property. Is there any reason


This node is exported by firmware


more (optional) properties cannot be added?


Kernel change seems simple over f/w enhancement..

Thanks
Hari

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

2017-04-13 Thread Michal Suchánek 
On Thu, 13 Apr 2017 01:59:13 +0530
Hari Bathini  wrote:

> On Friday 07 April 2017 07:16 PM, Michael Ellerman wrote:
> > Hari Bathini  writes:  
> >> On Friday 07 April 2017 07:24 AM, Michael Ellerman wrote:  
> >>> My preference would be that the fadump kernel "just works". If
> >>> it's using too much memory then the fadump kernel should do
> >>> whatever it needs to use less memory, eg. shrinking nr_cpu_ids
> >>> etc. Do we actually know *why* the fadump kernel is running out
> >>> of memory? Obviously large numbers of CPUs is one of the main
> >>> drivers (lots of stacks required). But other than that what is
> >>> causing the memory pressure? I would like some data on that
> >>> before we proceed.  
> >> Almost the same amount of memory in comparison with the memory
> >> required to boot the production kernel but that is unwarranted for
> >> fadump (dump capture) kernel.  
> > That's not data! :)
> >
> > The dump kernel is booted with *much* less memory than the
> > production kernel (that's the whole issue!) and so it doesn't need
> > to create struct pages for all that memory, which means it should
> > need less memory.
> >
> > The vfs caches are also sized based on the available memory, so they
> > should also shrink in the dump kernel.
> >
> > I want some actual numbers on what's driving the memory usage.
> >
> > I tried some of these parameters to see how much memory they would
> > save:  
> 
> Hi Michael,
> 
> Tried to get data to show parameters like numa=off &
> cgroup_disable=memory matter too but parameter nr_cpus=1 is making
> parameters like numa=off, cgroup_disable=memory insignificant. Also,
> these parameters not using much of early memory reservations is
> making quantification of memory saved for each of them that much more
> difficult. But I would still like to argue that passing additional
> parameters to fadump is better than enforcing nr_cpus=1 in the kernel
> for:
> 
>a) With makedumpfile tool supporting multi-threading it would make
> sense to leave the choice of how many CPUs to have, to the user.
> 
>b) Parameters like udev.children-max=2 can help to reduce the
> number of parallel executed events bringing down the memory pressure
> on fadump kernel (when it is booted with more than one CPU).
> 
>c) Ease of maintainability is better (considering any new kernel
> features with some memory to save or stability to gain on disabling,
> possible platform supports) with append approach over enforcing these 
> parameters
>   in the kernel.
> 
>d) It would give user the flexibility to disable unwanted kernel
> features in fadump kernel (numa=off, cgroup_disable=memory). For
> every feature enabled in the production kernel, fadump kernel will
> have the choice to
>   opt out of it, provided there is such cmdline option.

Hello,

can't the extra parameters be passed in the devicetree?

The docs say that the kernel can tell it's a fadump crash kernel by
checking the devicetree ibm,dump-kernel property. Is there any reason
more (optional) properties cannot be added?

Thanks

Michal

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

2017-04-12 Thread Hari Bathini 



On Friday 07 April 2017 07:16 PM, Michael Ellerman wrote:

Hari Bathini  writes:

On Friday 07 April 2017 07:24 AM, Michael Ellerman wrote:

My preference would be that the fadump kernel "just works". If it's
using too much memory then the fadump kernel should do whatever it needs
to use less memory, eg. shrinking nr_cpu_ids etc.
Do we actually know *why* the fadump kernel is running out of memory?
Obviously large numbers of CPUs is one of the main drivers (lots of
stacks required). But other than that what is causing the memory
pressure? I would like some data on that before we proceed.

Almost the same amount of memory in comparison with the memory
required to boot the production kernel but that is unwarranted for fadump
(dump capture) kernel.

That's not data! :)

The dump kernel is booted with *much* less memory than the production
kernel (that's the whole issue!) and so it doesn't need to create struct
pages for all that memory, which means it should need less memory.

The vfs caches are also sized based on the available memory, so they
should also shrink in the dump kernel.

I want some actual numbers on what's driving the memory usage.

I tried some of these parameters to see how much memory they would save:


Hi Michael,

Tried to get data to show parameters like numa=off & cgroup_disable=memory
matter too but parameter nr_cpus=1 is making parameters like numa=off,
cgroup_disable=memory insignificant. Also, these parameters not using much
of early memory reservations is making quantification of memory saved for
each of them that much more difficult. But I would still like to argue that
passing additional parameters to fadump is better than enforcing nr_cpus=1
in the kernel for:

  a) With makedumpfile tool supporting multi-threading it would make sense
 to leave the choice of how many CPUs to have, to the user.

  b) Parameters like udev.children-max=2 can help to reduce the number of
 parallel executed events bringing down the memory pressure on fadump
 kernel (when it is booted with more than one CPU).

  c) Ease of maintainability is better (considering any new kernel features
 with some memory to save or stability to gain on disabling, possible
 platform supports) with append approach over enforcing these 
parameters

 in the kernel.

  d) It would give user the flexibility to disable unwanted kernel features
 in fadump kernel (numa=off, cgroup_disable=memory). For every feature
 enabled in the production kernel, fadump kernel will have the 
choice to

 opt out of it, provided there is such cmdline option.


So, if parameters like
cgroup_disable=memory,

0 bytes saved.


transparent_hugepages=never,

0 bytes saved.


numa=off,

64KB saved.


nr_cpus=1,

3MB saved (vs 16 CPUs)



Hmmm... On a system with single core and 8GB memory, fadump kernel captures
dump successfully with 272MB passing nr_cpus=1 while it needed 320MB (+48MB)
to do the same without nr_cpus=1. So, while the early reservations saved 
is only a
couple of megabytes, it rubs off further in the boot process to reduce 
memory

consumption by nearly 50MB :)


Now maybe on your system those do save memory for some reason, but
please prove it to me. Otherwise I'm inclined to merge:

diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 8ff0dd4e77a7..03f1f253c372 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -79,8 +79,10 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
 * dump data waiting for us.
 */
fdm_active = of_get_flat_dt_prop(node, "ibm,kernel-dump", NULL);
-   if (fdm_active)
+   if (fdm_active) {
fw_dump.dump_active = 1;
+   nr_cpu_ids = 1;
+   }

/* Get the sizes required to store dump data for the firmware provided
 * dump sections.




Based on your suggestion, I am thinking of something like the below:

--
powerpc/fadump: reduce memory consumption for capture kernel

With fadump (dump capture) kernel booting like a regular kernel, it almost
needs the same amount of memory to boot as the production kernel, which is
unwarranted for a dump capture kernel. But with no option to disable some
of the unnecessary subsystems in fadump kernel, that much memory is wasted
on fadump, depriving the production kernel of that memory.

Introduce kernel parameter 'fadump_append=' that would take regular kernel
parameters as a comma separated list, to be enforced when fadump is active.
This 'fadump_append=' parameter can be leveraged to pass parameters like
nr_cpus=1, cgroup_disable=memory and numa=off, to disable unwarranted
resources/subsystems.

Also, ensure the log "Firmware-assisted dump is active" is printed early
in the boot process to put the subsequent fadump messages in context.

Suggested-by: Michael Ellerman 
Signed-off-by: Hari Bathini 
---

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

2017-04-07 Thread Hari Bathini 

Hi Michael,


On Friday 07 April 2017 07:16 PM, Michael Ellerman wrote:

Hari Bathini  writes:

On Friday 07 April 2017 07:24 AM, Michael Ellerman wrote:

My preference would be that the fadump kernel "just works". If it's
using too much memory then the fadump kernel should do whatever it needs
to use less memory, eg. shrinking nr_cpu_ids etc.
Do we actually know *why* the fadump kernel is running out of memory?
Obviously large numbers of CPUs is one of the main drivers (lots of
stacks required). But other than that what is causing the memory
pressure? I would like some data on that before we proceed.

Almost the same amount of memory in comparison with the memory
required to boot the production kernel but that is unwarranted for fadump
(dump capture) kernel.

That's not data! :)


I am collating the data. Sorry! I should have mentioned it :)


The dump kernel is booted with *much* less memory than the production
kernel (that's the whole issue!) and so it doesn't need to create struct
pages for all that memory, which means it should need less memory.


What I meant was, if we were to boot production kernel with mem=X, where 
X is
the smallest possible value to boot the kernel without resulting in an 
OOM, fadump

needed nearly the same amount to be reserved for it to capture dump without
hitting an OOM. But this was an observation on system with not so much 
memory.

Will try on a system with large memory and report back with data..



The vfs caches are also sized based on the available memory, so they
should also shrink in the dump kernel.

I want some actual numbers on what's driving the memory usage.

I tried some of these parameters to see how much memory they would save:


So, if parameters like
cgroup_disable=memory,

0 bytes saved.


Interesting.. was CONFIG_MEMCG set on the kernel?




transparent_hugepages=never,

0 bytes saved.


Not surprising unless transparent hugepages were used


numa=off,

64KB saved.


In the memory starved dump capture environment, every byte counts, I 
guess :)

Also, depends on the numa config?


nr_cpus=1,

3MB saved (vs 16 CPUs)


Now maybe on your system those do save memory for some reason, but
please prove it to me. Otherwise I'm inclined to merge:

diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 8ff0dd4e77a7..03f1f253c372 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -79,8 +79,10 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
 * dump data waiting for us.
 */
fdm_active = of_get_flat_dt_prop(node, "ibm,kernel-dump", NULL);
-   if (fdm_active)
+   if (fdm_active) {
fw_dump.dump_active = 1;
+   nr_cpu_ids = 1;
+   }

/* Get the sizes required to store dump data for the firmware provided
 * dump sections.


Necessary but not sufficient is the point I am trying to make. 
Apparently not

convincing enough. Will try and come back with relevant data :)

Thanks
Hari

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

2017-04-07 Thread Michael Ellerman 
Hari Bathini  writes:
> On Friday 07 April 2017 07:24 AM, Michael Ellerman wrote:
>> My preference would be that the fadump kernel "just works". If it's
>> using too much memory then the fadump kernel should do whatever it needs
>> to use less memory, eg. shrinking nr_cpu_ids etc.
>
>> Do we actually know *why* the fadump kernel is running out of memory?
>> Obviously large numbers of CPUs is one of the main drivers (lots of
>> stacks required). But other than that what is causing the memory
>> pressure? I would like some data on that before we proceed.
>
> Almost the same amount of memory in comparison with the memory
> required to boot the production kernel but that is unwarranted for fadump
> (dump capture) kernel.

That's not data! :)

The dump kernel is booted with *much* less memory than the production
kernel (that's the whole issue!) and so it doesn't need to create struct
pages for all that memory, which means it should need less memory.

The vfs caches are also sized based on the available memory, so they
should also shrink in the dump kernel.

I want some actual numbers on what's driving the memory usage.

I tried some of these parameters to see how much memory they would save:

> So, if parameters like
> cgroup_disable=memory,

0 bytes saved.

> transparent_hugepages=never,

0 bytes saved.

> numa=off,

64KB saved.

> nr_cpus=1,

3MB saved (vs 16 CPUs)


Now maybe on your system those do save memory for some reason, but
please prove it to me. Otherwise I'm inclined to merge:

diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 8ff0dd4e77a7..03f1f253c372 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -79,8 +79,10 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
 * dump data waiting for us.
 */
fdm_active = of_get_flat_dt_prop(node, "ibm,kernel-dump", NULL);
-   if (fdm_active)
+   if (fdm_active) {
fw_dump.dump_active = 1;
+   nr_cpu_ids = 1;
+   }
 
/* Get the sizes required to store dump data for the firmware provided
 * dump sections.

cheers

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

2017-04-07 Thread Hari Bathini 



On Friday 07 April 2017 12:54 PM, Hari Bathini wrote:

Hi Michael,


On Friday 07 April 2017 07:24 AM, Michael Ellerman wrote:

Hari Bathini  writes:


In case of fadump, capture (fadump) kernel boots like a normal kernel.
While this has its advantages, the capture kernel would initialize all
the components like normal kernel, which may not necessarily be needed
for a typical dump capture kernel. So, fadump capture kernel ends up
needing more memory than a typical (read kdump) capture kernel to boot.

This can be overcome by introducing parameters like fadump_nr_cpus=1,
similar to nr_cpus=1 parameter, applicable only when fadump is active.
But this approach needs introduction of special parameters applicable
only when fadump is active (capture kernel), for every parameter that
reduces memory/resource consumption.

A better approach would be to pass extra parameters to fadump capture
kernel. As firmware leaves the memory contents intact from the time of
crash till the new kernel is booted up, parameters to append to capture
kernel can be saved in real memory region and retrieved later when the
capture kernel is in its early boot process for appending to command
line parameters.

This patch introduces a new node /sys/kernel/fadump_cmdline_append to
specify the parameters to pass to fadump capture kernel, saves them in
real memory region and appends these parameters to capture kernel early
in its boot process.

As we discussed on IRC I don't really like this.

It's clever, (ab)using the fact that the first kernel's memory is left
intact. But it's also a bit gross :)


No doubt. It is an ugly trick :)


It also has a few real problems, like hard coding 128MB as the handover
location. You may not have memory there, or it may be reserved.



Yeah, there is a chance that appending parameters is not possible
like in the scenarios you mentioned above. My intention behind this
hack is to build on this handover area later to probably pass off a
special intird which brings down the dump capture time and memory
consumption further. But to put it in your words, it would be abusing
it even more :P . So, I would take it as a road not worthing taking..


My preference would be that the fadump kernel "just works". If it's
using too much memory then the fadump kernel should do whatever it needs
to use less memory, eg. shrinking nr_cpu_ids etc.



Do we actually know *why* the fadump kernel is running out of memory?
Obviously large numbers of CPUs is one of the main drivers (lots of
stacks required). But other than that what is causing the memory
pressure? I would like some data on that before we proceed.


Almost the same amount of memory in comparison with the memory
required to boot the production kernel but that is unwarranted for fadump
(dump capture) kernel. Let's say the production kernel is configured for
memory cgroups or hugepages which is not required in a dump capture 
kernel
but with no option to say so, we are wasting that much more memory on 
fadump

and eventually depriving the production kernel of that memory.

So, if parameters like cgroup_disable=memory, 
transparent_hugepages=never,
numa=off, nr_cpus=1, etc.. are passed to fadump (dump capture) kernel 
it would
be beneficial. Not to mention any future additions to the kernel that 
increase the

footprint of a production kernel..


If we *must* have a way to pass command line arguments to the fadump
kernel then I think we should just use a command line argument that
specifies them.

eg: 
fadump_append=nr_cpus=1,use_less_memory,some_other_obscure_parameter=100





Hmmm.. this sounds like a better interface. But I would like know your 
preference on

how to process fadump_append parameter:

1. Modify cmdline early in fadump kernel boot process (before parsing 
parameters) to change
   fadump_append="nr_cpus=1 cgroup_disable=memory" in cmdline to 
"nr_cpus=1 cgroup_disable=memory"
   so that fadump doesn't have to bother about processing this 
parameters later.
2. A parse function in fadump to parse fadump_append parameters. A 
function similar to parse_early_param()

   meant for fadump_append parameter alone..
3. fadump code processes fadump_append for each parameter passed in it.

The third one sounds like a nightmare to me as we need to make fadump 
code aware of every new parameter

we want to enforce on fadump..



I prefer option 2 for it is simple and cleaner..

Thanks
Hari

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

2017-04-07 Thread Hari Bathini 

Hi Michael,


On Friday 07 April 2017 07:24 AM, Michael Ellerman wrote:

Hari Bathini  writes:


In case of fadump, capture (fadump) kernel boots like a normal kernel.
While this has its advantages, the capture kernel would initialize all
the components like normal kernel, which may not necessarily be needed
for a typical dump capture kernel. So, fadump capture kernel ends up
needing more memory than a typical (read kdump) capture kernel to boot.

This can be overcome by introducing parameters like fadump_nr_cpus=1,
similar to nr_cpus=1 parameter, applicable only when fadump is active.
But this approach needs introduction of special parameters applicable
only when fadump is active (capture kernel), for every parameter that
reduces memory/resource consumption.

A better approach would be to pass extra parameters to fadump capture
kernel. As firmware leaves the memory contents intact from the time of
crash till the new kernel is booted up, parameters to append to capture
kernel can be saved in real memory region and retrieved later when the
capture kernel is in its early boot process for appending to command
line parameters.

This patch introduces a new node /sys/kernel/fadump_cmdline_append to
specify the parameters to pass to fadump capture kernel, saves them in
real memory region and appends these parameters to capture kernel early
in its boot process.

As we discussed on IRC I don't really like this.

It's clever, (ab)using the fact that the first kernel's memory is left
intact. But it's also a bit gross :)


No doubt. It is an ugly trick :)


It also has a few real problems, like hard coding 128MB as the handover
location. You may not have memory there, or it may be reserved.



Yeah, there is a chance that appending parameters is not possible
like in the scenarios you mentioned above. My intention behind this
hack is to build on this handover area later to probably pass off a
special intird which brings down the dump capture time and memory
consumption further. But to put it in your words, it would be abusing
it even more :P . So, I would take it as a road not worthing taking..


My preference would be that the fadump kernel "just works". If it's
using too much memory then the fadump kernel should do whatever it needs
to use less memory, eg. shrinking nr_cpu_ids etc.



Do we actually know *why* the fadump kernel is running out of memory?
Obviously large numbers of CPUs is one of the main drivers (lots of
stacks required). But other than that what is causing the memory
pressure? I would like some data on that before we proceed.


Almost the same amount of memory in comparison with the memory
required to boot the production kernel but that is unwarranted for fadump
(dump capture) kernel. Let's say the production kernel is configured for
memory cgroups or hugepages which is not required in a dump capture kernel
but with no option to say so, we are wasting that much more memory on fadump
and eventually depriving the production kernel of that memory.

So, if parameters like cgroup_disable=memory, transparent_hugepages=never,
numa=off, nr_cpus=1, etc.. are passed to fadump (dump capture) kernel it 
would
be beneficial. Not to mention any future additions to the kernel that 
increase the

footprint of a production kernel..


If we *must* have a way to pass command line arguments to the fadump
kernel then I think we should just use a command line argument that
specifies them.

eg: fadump_append=nr_cpus=1,use_less_memory,some_other_obscure_parameter=100




Hmmm.. this sounds like a better interface. But I would like know your 
preference on

how to process fadump_append parameter:

1. Modify cmdline early in fadump kernel boot process (before parsing 
parameters) to change
   fadump_append="nr_cpus=1 cgroup_disable=memory" in cmdline to 
"nr_cpus=1 cgroup_disable=memory"
   so that fadump doesn't have to bother about processing this 
parameters later.
2. A parse function in fadump to parse fadump_append parameters. A 
function similar to parse_early_param()

   meant for fadump_append parameter alone..
3. fadump code processes fadump_append for each parameter passed in it.

The third one sounds like a nightmare to me as we need to make fadump 
code aware of every new parameter

we want to enforce on fadump..

Thanks
Hari

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

2017-04-06 Thread Michael Ellerman 
Hari Bathini  writes:

> In case of fadump, capture (fadump) kernel boots like a normal kernel.
> While this has its advantages, the capture kernel would initialize all
> the components like normal kernel, which may not necessarily be needed
> for a typical dump capture kernel. So, fadump capture kernel ends up
> needing more memory than a typical (read kdump) capture kernel to boot.
>
> This can be overcome by introducing parameters like fadump_nr_cpus=1,
> similar to nr_cpus=1 parameter, applicable only when fadump is active.
> But this approach needs introduction of special parameters applicable
> only when fadump is active (capture kernel), for every parameter that
> reduces memory/resource consumption.
>
> A better approach would be to pass extra parameters to fadump capture
> kernel. As firmware leaves the memory contents intact from the time of
> crash till the new kernel is booted up, parameters to append to capture
> kernel can be saved in real memory region and retrieved later when the
> capture kernel is in its early boot process for appending to command
> line parameters.
>
> This patch introduces a new node /sys/kernel/fadump_cmdline_append to
> specify the parameters to pass to fadump capture kernel, saves them in
> real memory region and appends these parameters to capture kernel early
> in its boot process.

As we discussed on IRC I don't really like this.

It's clever, (ab)using the fact that the first kernel's memory is left
intact. But it's also a bit gross :)

It also has a few real problems, like hard coding 128MB as the handover
location. You may not have memory there, or it may be reserved.


My preference would be that the fadump kernel "just works". If it's
using too much memory then the fadump kernel should do whatever it needs
to use less memory, eg. shrinking nr_cpu_ids etc.

Do we actually know *why* the fadump kernel is running out of memory?
Obviously large numbers of CPUs is one of the main drivers (lots of
stacks required). But other than that what is causing the memory
pressure? I would like some data on that before we proceed.


If we *must* have a way to pass command line arguments to the fadump
kernel then I think we should just use a command line argument that
specifies them.

eg: fadump_append=nr_cpus=1,use_less_memory,some_other_obscure_parameter=100


cheers

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

2017-02-07 Thread Hari Bathini 
In case of fadump, capture (fadump) kernel boots like a normal kernel.
While this has its advantages, the capture kernel would initialize all
the components like normal kernel, which may not necessarily be needed
for a typical dump capture kernel. So, fadump capture kernel ends up
needing more memory than a typical (read kdump) capture kernel to boot.

This can be overcome by introducing parameters like fadump_nr_cpus=1,
similar to nr_cpus=1 parameter, applicable only when fadump is active.
But this approach needs introduction of special parameters applicable
only when fadump is active (capture kernel), for every parameter that
reduces memory/resource consumption.

A better approach would be to pass extra parameters to fadump capture
kernel. As firmware leaves the memory contents intact from the time of
crash till the new kernel is booted up, parameters to append to capture
kernel can be saved in real memory region and retrieved later when the
capture kernel is in its early boot process for appending to command
line parameters.

This patch introduces a new node /sys/kernel/fadump_cmdline_append to
specify the parameters to pass to fadump capture kernel, saves them in
real memory region and appends these parameters to capture kernel early
in its boot process.

Signed-off-by: Hari Bathini 
---

Changes from v1:
* Not changing dump format version to keep compatibility intact. Using
  start and end markers instead, to check sanity of handover area.
* Checking for memory overlap with current kernel before setting up
  a handover area.


 arch/powerpc/include/asm/fadump.h |   31 +++
 arch/powerpc/kernel/fadump.c  |  158 +
 arch/powerpc/kernel/prom.c|   22 +
 3 files changed, 210 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/fadump.h 
b/arch/powerpc/include/asm/fadump.h
index 0031806..e6b3dc0 100644
--- a/arch/powerpc/include/asm/fadump.h
+++ b/arch/powerpc/include/asm/fadump.h
@@ -24,6 +24,8 @@
 
 #ifdef CONFIG_FA_DUMP
 
+#include 
+
 /*
  * The RMA region will be saved for later dumping when kernel crashes.
  * RMA is Real Mode Area, the first block of logical memory address owned
@@ -126,6 +128,13 @@ struct fw_dump {
/* cmd line option during boot */
unsigned long   reserve_bootvar;
 
+   /*
+* Area to pass info to capture (fadump) kernel. For now,
+* we are only passing parameters to append.
+*/
+   unsigned long   handover_area_start;
+   unsigned long   handover_area_size;
+
unsigned long   fadumphdr_addr;
unsigned long   cpu_notes_buf;
unsigned long   cpu_notes_buf_size;
@@ -159,6 +168,27 @@ static inline u64 str_to_u64(const char *str)
 #define FADUMP_CRASH_INFO_MAGICSTR_TO_HEX("FADMPINF")
 #define REGSAVE_AREA_MAGIC STR_TO_HEX("REGSAVE")
 
+/*
+ * Start address for the area to pass off certain configuration details
+ * like parameters to append to the commandline for a capture (fadump) kernel.
+ * Will refer to this area as handover area henceforth. Setting start address
+ * of handover area to 128MB as this area needs to be accessed in realmode.
+ */
+#define FADUMP_HANDOVER_AREA_START (1UL << 27)
+#define FADUMP_HANDOVER_AREA_SIZE  (sizeof(struct fadump_handover_info) \
++ H_END_MARKER_SIZE)
+
+#define H_AREA_START_MARKERSTR_TO_HEX("HDRSTART")
+#define H_AREA_END_MARKER  STR_TO_HEX("HOVEREND")
+#define H_END_MARKER_SIZE  8
+
+/* config info to be passed to capture kernel */
+struct fadump_handover_info {
+   u64 start_marker;
+   u64 size;
+   charparams[COMMAND_LINE_SIZE/2];
+};
+
 /* The firmware-assisted dump format.
  *
  * The register save area is an area in the partition's memory used to preserve
@@ -200,6 +230,7 @@ struct fad_crash_memory_ranges {
 
 extern int early_init_dt_scan_fw_dump(unsigned long node,
const char *uname, int depth, void *data);
+extern char *get_fadump_parameters_realmode(void);
 extern int fadump_reserve_mem(void);
 extern int setup_fadump(void);
 extern int is_fadump_active(void);
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 8f0c7c5..eab26e9 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -41,7 +41,6 @@
 #include 
 #include 
 #include 
-#include 
 
 static struct fw_dump fw_dump;
 static struct fadump_mem_struct fdm;
@@ -51,6 +50,8 @@ static DEFINE_MUTEX(fadump_mutex);
 struct fad_crash_memory_ranges crash_memory_ranges[INIT_CRASHMEM_RANGES];
 int crash_mem_ranges;
 
+extern char _stext[], _end[];
+
 /* Scan the Firmware Assisted dump configuration details. */
 int __init early_init_dt_scan_fw_dump(unsigned long node,
const char *uname, int depth, void *data)
@@ -74,6 +75,9 @@ int __init early_init_dt_scan_fw_dump(unsigned long