Re: Not booting BSP in kdump kernel (Was: Re: 32TB kdump)

[HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>]

(2013/07/06 0:21), Vivek Goyal wrote:
> On Thu, Jul 04, 2013 at 11:03:46AM +0900, HATAYAMA Daisuke wrote:
>
> [..]
>>> It took around 400 seconds to capture compressed dump on disk and out of
>>> that 326 seconds were consumed by compression only. Around 80% of total
>>> dump time in this case was attributed to compression.
>>>
>>> So this sounds like the next big fish to go after. Using lzo and
>>> snappy might help a bit. But I think bringing up more cpus in second
>>> kernel should help too.
>>>
>>> What's the status of your patches to bring up multiple cpus in kdump
>>> kernel. Are you planning to push these upstream?
>>>
>>
>> My next patch is the same as in diff:
>>
>> http://lkml.indiana.edu/hypermail/linux/kernel/1210.2/00014.html
>>
>> Now there's need to compare the idea with Eric's suggestion that unsets BSP flag from boot cpu
>> at the boot time of 1st kernel, which is very simpler than the idea of mine. However,
>> HPA pointed out that the Eric's idea could affect some sort of firmware.
>> I'm investigating that now.
>>
>> Candidates I've found so far is ACPI firmware. ACPI specification describes that in FADT part,
>> SMI_CMD and other SMI releated commands need to be called on boot processor, i.e. cpu with BSP
>> flag; See Table 5-34 in ACPI spec 5.0. I associate this to restriction of cpu hotplug that boot
>> processor cannot be physically removed. Also, there's comment in __acpi_os_execute():
>>
>>          /*
>>           * On some machines, a software-initiated SMI causes corruption unless
>>           * the SMI runs on CPU 0.  An SMI can be initiated by any AML, but
>>           * typically it's done in GPE-related methods that are run via
>>           * workqueues, so we can avoid the known corruption cases by always
>>           * queueing on CPU 0.
>>           */
>>          ret = queue_work_on(0, queue, &dpc->work);
>>
>> But I don't know whether the SMI requires even BSP flag set or not. I need suggestion from
>> experts around this field.
>>
>> I'll post the patch next week and send cc to some experts in order to fill the patch
>> description with concrete description about what kind of firmware is affected by unsetting
>> BSP flag.
>
> Ok. BTW, did clearing BSP flag work for you experimentally? Hpa mentioned
> that it did not for Fenghua.
>

My experiment is still not enough. Unseting BSP flag only didn't affect system behavior. It's
necessary to trigger some firmware whose work depends on BSP flag set. Previously I tried
hibernation and suspend because I suspect they depend on BSP flag set but apparently they worked.

Luckily, I can use this week system with acpi hot plugging feature on which I can trigger
SMI_CMD port as described in ACPI specification. I plan to test logic of unsetting BSP flag
on the system.

> To me looking into ACPI/MP tables to figure out which is BSP and not
> bringing up that cpu sounds simple and one does not have to worry
> about dealing with side affects of clearing BSP bit, if any.
>
> CCing Eric to figure out if he is particular about clearing BSP bit
> solution or is willing to accept the solution of booting N-1 cpus
> in kdump kernel by not bringing up BSP.
>
> Thanks
> Vivek
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>


-- 
Thanks.
HATAYAMA, Daisuke


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