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

[Lisa Mitchell]

On Fri, 2013-12-06 at 05:35 -0700, Lisa Mitchell wrote:
> 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
> 
I have now tested the version 9 patch on  a 2.6.32 base on the max
cpu/large IO configuration, and got 8 out of 8 successful dumps, (7 with
nr_cpus=8, and one with nr_cpus=16).