From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753478AbcLIFPL (ORCPT ); Fri, 9 Dec 2016 00:15:11 -0500 Received: from szxga01-in.huawei.com ([58.251.152.64]:57690 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752637AbcLIFPK (ORCPT ); Fri, 9 Dec 2016 00:15:10 -0500 Message-ID: <584A3D84.6040004@huawei.com> Date: Fri, 9 Dec 2016 13:13:40 +0800 From: zhong jiang User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: CC: Xunlei Pang , , , , Subject: Re: [PATCH v2] kexec: add cond_resched into kimage_alloc_crash_control_pages References: <1481164674-42775-1-git-send-email-zhongjiang@huawei.com> <58492ADC.4070305@redhat.com> In-Reply-To: <58492ADC.4070305@redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.29.68] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/12/8 17:41, Xunlei Pang wrote: > On 12/08/2016 at 10:37 AM, zhongjiang wrote: >> From: zhong jiang >> >> A soft lookup will occur when I run trinity in syscall kexec_load. >> the corresponding stack information is as follows. >> >> [ 237.235937] BUG: soft lockup - CPU#6 stuck for 22s! [trinity-c6:13859] >> [ 237.242699] Kernel panic - not syncing: softlockup: hung tasks >> [ 237.248573] CPU: 6 PID: 13859 Comm: trinity-c6 Tainted: G O L ----V------- 3.10.0-327.28.3.35.zhongjiang.x86_64 #1 >> [ 237.259984] Hardware name: Huawei Technologies Co., Ltd. Tecal BH622 V2/BC01SRSA0, BIOS RMIBV386 06/30/2014 >> [ 237.269752] ffffffff8187626b 0000000018cfde31 ffff88184c803e18 ffffffff81638f16 >> [ 237.277471] ffff88184c803e98 ffffffff8163278f 0000000000000008 ffff88184c803ea8 >> [ 237.285190] ffff88184c803e48 0000000018cfde31 ffff88184c803e67 0000000000000000 >> [ 237.292909] Call Trace: >> [ 237.295404] [] dump_stack+0x19/0x1b >> [ 237.301352] [] panic+0xd8/0x214 >> [ 237.306196] [] watchdog_timer_fn+0x1cc/0x1e0 >> [ 237.312157] [] ? watchdog_enable+0xc0/0xc0 >> [ 237.317955] [] __hrtimer_run_queues+0xd2/0x260 >> [ 237.324087] [] hrtimer_interrupt+0xb0/0x1e0 >> [ 237.329963] [] ? call_softirq+0x1c/0x30 >> [ 237.335500] [] local_apic_timer_interrupt+0x37/0x60 >> [ 237.342228] [] smp_apic_timer_interrupt+0x3f/0x60 >> [ 237.348771] [] apic_timer_interrupt+0x6d/0x80 >> [ 237.354967] [] ? kimage_alloc_control_pages+0x80/0x270 >> [ 237.362875] [] ? kmem_cache_alloc_trace+0x1ce/0x1f0 >> [ 237.369592] [] ? do_kimage_alloc_init+0x1f/0x90 >> [ 237.375992] [] kimage_alloc_init+0x12a/0x180 >> [ 237.382103] [] SyS_kexec_load+0x20a/0x260 >> [ 237.387957] [] system_call_fastpath+0x16/0x1b >> >> the first time allocate control pages may take too much time because >> crash_res.end can be set to a higher value. we need to add cond_resched >> to avoid the issue. >> >> The patch have been tested and above issue is not appear. >> >> Signed-off-by: zhong jiang >> --- >> kernel/kexec_core.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c >> index 5616755..bfc9621 100644 >> --- a/kernel/kexec_core.c >> +++ b/kernel/kexec_core.c >> @@ -441,6 +441,8 @@ static struct page *kimage_alloc_crash_control_pages(struct kimage *image, >> while (hole_end <= crashk_res.end) { >> unsigned long i; >> >> + cond_resched(); >> + > I can't see why it would take a long time to loop inside, the job it does is simply to find a control area > not overlapped with image->segment[], you can see the loop "for (i = 0; i < image->nr_segments; i++)", > @hole_end will be advanced to the end of its next nearby segment once overlap was detected each loop, > also there are limited (<=16) segments, so it won't take long to locate the right area. > > Am I missing something? > > Regards, > Xunlei if the crashkernel = auto is set in cmdline. it represent crashk_res.end will exceed to 4G, the first allocate control pages will loop million times. if we set crashk_res.end to the higher value manually, you can image.... Thanks zhongjiang >> if (hole_end > KEXEC_CRASH_CONTROL_MEMORY_LIMIT) >> break; >> /* See if I overlap any of the segments */ > > . >