[PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM
chaowang at redhat.com
Mon Nov 4 09:38:50 EST 2013
On 10/28/13 at 11:12am, Vivek Goyal wrote:
> On Thu, Oct 24, 2013 at 10:48:29PM -0700, Yinghai Lu wrote:
> > On Thu, Oct 24, 2013 at 12:27 PM, Vivek Goyal <vgoyal at redhat.com> wrote:
> > > On Thu, Oct 24, 2013 at 12:24:57PM -0700, Yinghai Lu wrote:
> > >> On Thu, Oct 24, 2013 at 12:18 PM, Vivek Goyal <vgoyal at redhat.com> wrote:
> > >> > On Thu, Oct 24, 2013 at 12:15:25PM -0700, Yinghai Lu wrote:
> > >> >
> > >> > Also keeping things simple by not trying to *impose* a new crashkernel=
> > >> > syntax on existing crashkernel=xM users.
> > >>
> > >> Existing user that have crashkernel=xM working with their old kernel
> > >> and old kexec-tools, they still could keep their old command line and
> > >> old kexec-tools
> > >> with new updated kernel.
> > >> We should not change semantics to surprise them.
> > >
> > > Old users will get reservation still below 896MB.
> > >
> > > It will go above 896MB only if memory could not be allocated below 896MB.
> > >
> > > In the past reservation will fail and kexec-tools will fail.
> > > Now reservation will succeed but kexec-tools will fail.
> > >
> > > So end result a user sees is that kexec-tools fails. So I don't see how
> > > we are breaking existing installations or user setups.
> > case could be: if user add more memory and put more pcie cards, and
> > second kernel will need more ram and OOM there.
> Now makedumpfile supports cyclic mode by default. So one does not have
> to necessarily linearly scale reserved memory based on physical memory
> present in the box.
> > so user could just increase crashkernel=512M to crashkernel=1G.
> If user has new makedumpfile, OOM should not happen and one should not
> have to increase memory reservation.
> > without Cong's patch, kernel will fail to reserve, and user would dig
> > to change it
> > to crashkernel=1G,high, and update kexec-tools.
> > with Cong's patch, kernel will reserve other range like between 896
> > and 4G, old kexec-tools either
> > fail to load second kernel or hang in purgatory or early stage of
> > second kernel, or other unknown behavior.
> I understand your concern about memory being reserved high and kexec
> just hanging. Only thing I am arguing is that the number of cases where
> it will happen is small.
> - First of all for all old existing kexec-tools memory will stil come
> from 896MB.
> - Old kexec-tools enforced that purgatory is loaded below 2G. So if
> memory is reserved above 2G, kexec-tools will fail.
> So only problematic case seems to be that if user increased crashkernel=X
> value and memory got reserved between 896M and 2G. But this is not same
> as breaking old setups as old setups anyway never worked with this
> You argument that user will research and upgrade kexec-tools and use
> crashkernel=X,high, then it holds true for the case where memory is
> reserved between 896M and 2G.
> I personally think that it is easier for a user to not change any
> kernel parameters with kernel and kexec-tools upgrade and still be
> able to work with large memory systems. So the benefit of extending
> the semantics of existing parameter seems to be outweighing the downside
> of side, IMHO.
> > I would think first path is much clear and predicted.
> > If my memory is right, HPA did not like idea that we try below 896M,
> > and then under 4G and then above 4G.
> hpa, I know you did not like the idea in the past. Is it still the case.
Do you still not like this idea? Could you make it more clear to us
> IMHO, I like the fact that existing users still be able to work with
> crashkernel=X and not forced to switch to crashkernel=x,high and also incur
> the penalty of reserving extra memory for software iotlb.
More information about the kexec