From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Uw7gl-0004LG-GO for kexec@lists.infradead.org; Mon, 08 Jul 2013 09:24:57 +0000 Received: from m4.gw.fujitsu.co.jp (unknown [10.0.50.74]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id CA3F93EE081 for ; Mon, 8 Jul 2013 18:24:25 +0900 (JST) Received: from smail (m4 [127.0.0.1]) by outgoing.m4.gw.fujitsu.co.jp (Postfix) with ESMTP id BBD8945DE4F for ; Mon, 8 Jul 2013 18:24:25 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (s4.gw.fujitsu.co.jp [10.0.50.94]) by m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 9CAD245DE4D for ; Mon, 8 Jul 2013 18:24:25 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 78B2C1DB802F for ; Mon, 8 Jul 2013 18:24:25 +0900 (JST) Received: from m1001.s.css.fujitsu.com (m1001.s.css.fujitsu.com [10.240.81.139]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 20A851DB8037 for ; Mon, 8 Jul 2013 18:24:25 +0900 (JST) Message-ID: <51DA8521.2010701@jp.fujitsu.com> Date: Mon, 08 Jul 2013 18:23:45 +0900 From: HATAYAMA Daisuke MIME-Version: 1.0 Subject: Re: Not booting BSP in kdump kernel (Was: Re: 32TB kdump) References: <20130627211725.GM4899@redhat.com> <51D0D399.1070501@jp.fujitsu.com> <20130701160635.GB9840@redhat.com> <51D3D15D.5090600@jp.fujitsu.com> <20130703130324.GA1460@redhat.com> <51D4D802.3050503@jp.fujitsu.com> <20130705152115.GD10152@redhat.com> In-Reply-To: <20130705152115.GD10152@redhat.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "kexec" Errors-To: kexec-bounces+dwmw2=twosheds.infradead.org@lists.infradead.org To: Vivek Goyal Cc: kexec@lists.infradead.org, Cliff Wickman , "Eric W. Biederman" (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