[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1312278664.4881.35.camel@br98xy6r>
Date: Tue, 02 Aug 2011 11:51:04 +0200
From: Michael Holzheu <holzheu@...ux.vnet.ibm.com>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: ebiederm@...ssion.com, mahesh@...ux.vnet.ibm.com, hbabu@...ibm.com,
oomichi@....nes.nec.co.jp, horms@...ge.net.au,
schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-s390@...r.kernel.org
Subject: Re: [patch v2 01/10] kdump: Add KEXEC_CRASH_CONTROL_MEMORY_LIMIT
Hello Vivek,
On Mon, 2011-08-01 at 16:16 -0400, Vivek Goyal wrote:
> On Wed, Jul 27, 2011 at 02:55:05PM +0200, Michael Holzheu wrote:
> > From: Michael Holzheu <holzheu@...ux.vnet.ibm.com>
> >
> > On s390 there is a different KEXEC_CONTROL_MEMORY_LIMIT for the normal and
> > the kdump kexec case. Therefore this patch introduces a new macro
> > KEXEC_CRASH_CONTROL_MEMORY_LIMIT. This is set to
> > KEXEC_CONTROL_MEMORY_LIMIT for all architectures that do not define
> > KEXEC_CRASH_CONTROL_MEMORY_LIMIT.
>
> Hi Michael,
>
> Curious that why limit is different for kexec and kdump cases on s390
> only.
The standard kexec relocate_kernel code calls a machine instruction that
must run below 2 GiB. For kdump we currently do not use the control page
at all because no segments have to be moved in that case. Perhaps I am
still missing something here?
Michael
--
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/
Powered by blists - more mailing lists