From: HATAYAMA Daisuke <d.hatayama@xxxxxxxxxxxxxx> Subject: Re: [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP Date: Tue, 16 Oct 2012 14:03:13 +0900 > From: "Yu, Fenghua" <fenghua.yu at intel.com> > Subject: RE: [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP > Date: Tue, 16 Oct 2012 04:51:36 +0000 > >>> -----Original Message----- >>> From: HATAYAMA Daisuke [mailto:d.hatayama at jp.fujitsu.com] >>> Sent: Monday, October 15, 2012 9:35 PM >>> To: linux-kernel at vger.kernel.org; kexec at lists.infradead.org; >>> x86 at kernel.org >>> Cc: mingo at elte.hu; tglx at linutronix.de; hpa at zytor.com; Brown, Len; Yu, >>> Fenghua; vgoyal at redhat.com; ebiederm at xmission.com; >>> grant.likely at secretlab.ca; rob.herring at calxeda.com; >>> d.hatayama at jp.fujitsu.com >>> Subject: [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP >>> >>> Multiple CPUs are useful for CPU-bound processing like compression and >>> I do want to use compression to generate crash dump quickly. But now >>> we cannot wakeup the 2nd and later cpus in the kdump 2nd kernel if >>> crash happens on AP. If crash happens on AP, kexec enters the 2nd >>> kernel with the AP, and there BSP in the 1st kernel is expected to be >>> haling in the 1st kernel or possibly in any fatal system error state. >>> >>> To wake up AP, we use the method called INIT-INIT-SIPI. INIT causes >>> BSP to jump into BIOS init code. A typical visible behaviour is hang >>> or immediate reset, depending on the BIOS init code. >>> >>> AP can be initiated by INIT even in a fatal state: MP spec explains >>> that processor-specific INIT can be used to recover AP from a fatal >>> system error. On the other hand, there's no method for BSP to recover; >>> it might be possible to do so by NMI plus any hand-coded reset code >>> that is carefully designed, but at least I have no idea in this >>> direction now. >> >> In my BSP hotplug patchset, BPS is waken up by NMI. The patchset is >> not in tip tree yet. >> >> BSP hotplug patchset can be found at https://lkml.org/lkml/2012/10/12/336 >> >>> >>> Therefore, the idea I do in this patch set is simply to disable BSP if >>> vboot cpu is AP. >>> >> >> The BSP hotplug patchset will be useful for you goal. With the BSP hotplug >> patcheset, you can wake up BSP and don't need to disable it. >> >>> My motivation is to use multiple CPUs in order to quickly generate >>> crash dump on the machine with huge amount of memory. I assume such >>> machine tends to also have a lot of CPUs. So disabling one CPU would >>> be no problem. >> >> Luckily you don't need to disable any CPU to archive your goal with >> the BSP hotplug pachest:) >> >> On a dual core/single thread machine, this means you get 100% performance >> boost with BSP's help. >> >> Plus crash dump kernel code is better structured by not treating BSP >> specially. >> > > Hello Fenghua. > > I've of course noticed your patch set and locally tested, but I saw > NMI to BSP failed in the 2nd kernel. I'll send a log to you later. > > BTW, I tested with your previous v8 patch set. Did you change > something during v8 to v9 relevant to this issue? > I've fogetten saying one comment that your patch distinguish BSP by CPU#0. CPU#0 is assigned to the boot cpu, which can be AP in the kdump 2nd kernel. Distinguishing BSP by CPU#0 is not enough here. I have my local patch set based on your v8 patch doing this, but NMI to BSP failed. I guess this comes from the difference of BSP states: halting in play dead in your NMI method and halting in the 1st kernel on crash or possibly in a fatal system error on actual situation. Thanks. HATAYAMA, Daisuke
