Re: [PATCH v9] x86, apic, kexec, Documentation: Add disable_cpu_apic kernel parameter

From: Lisa Mitchell <lisa.mitchell@hp.com>
To: "Hoemann, Jerry" <jerry.hoemann@hp.com>
Cc: kexec <kexec@lists.infradead.org>
Subject: Re: [PATCH v9] x86, apic, kexec, Documentation: Add disable_cpu_apic kernel parameter
Date: Fri, 06 Dec 2013 05:34:59 -0700	[thread overview]
Message-ID: <1386333299.17054.29.camel@lisamlinux.fc.hp.com> (raw)
In-Reply-To: <20131205215824.GA29585@anatevka.fc.hp.com>

On Thu, 2013-12-05 at 21:58 +0000, Hoemann, Jerry wrote:
> 
> Sorry if you're getting multiple copies, but i have had problems with
> my subscription to the kexec mailing list and am resending.
> 
> 
> 
> On Tue, Dec 03, 2013 at 10:25:36AM -0500, Vivek Goyal wrote:
> >
> > Hi Hatayama,
> >
> > We are almost there. A minor nit. Why have we specified KEXEC here. This
> > parameter disabled_cpu_apicid does not seem to dependon CONFIG_KEXEC?
> >
> > Jerry, this patch looks good to me. Does it work on your system?
> >
> > Thanks
> > Vivek
> 
> 
> Vivek,  Hatayama,
> 
> I've back ported v9 of this patch to 2.6.32 and 3.0.80 based kernels to
> test with existing distros.
> 
> I've tested on our smaller prototype server specifying nr_cpus=8/maxcpus=8
> to the capture kernel.  One hundred iterations (echo c > /proc/sysrq-trigger)
> varying target cpu and system load to each kernel.
> 
> The 2.6.32 based distro kernel showed the < 5% soft lockup
> (still unresolved) during boot of capture kernel.  This is
> something i've seen on all versions of the patch that i've tested.
> 
> The 3.0.80 based distro kernel has had zero failures.
> 
> I have not had a chance to test upstream kernels or on
> our larger prototype configuration.
> 
> We still plan to test on our larger prototype.  Testing of
> prior versions of the patch on the larger systems didn't show
> problems w/ this functionality and I don't anticipate we'll
> find anything this time either.
> 
> I am okay with this patch being accepted upstream and working
> the intermittent 2.6.32 failures separately.
> 
> 
> Jerry
> 

Another update, I have tested our max cpu configuration prototype, with
a fairly large IO config with the backported 3.0.80 kernel Jerry
mentions above with the v9 patch backported, and this system got 7 out
of 7 successful dumps, with max_cpus=8, so far in testing. This system
has a a fairly large IO configuration too, such that intermittently
booting the crashkernel with 1 cpu  the crashkernel boot would hang due
to IRQ for system disk not getting assigned.   So this is early
indication that this patch is working well on larger IO configurations.

I plan to test with the 2.6.32 base with v9 patch over the weekend on
this large configuration.   The system takes much longer to dump than
the minimum config, so it is harder to build up as many iterations over
a short time, plus I have to share the system with others.  

Thanks,

Lisa Mitchell

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec