From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from out01.mta.xmission.com ([166.70.13.231]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1cEnuq-00061u-Uv for kexec@lists.infradead.org; Thu, 08 Dec 2016 01:54:34 +0000 From: ebiederm@xmission.com (Eric W. Biederman) References: <1481116631-33527-1-git-send-email-zhongjiang@huawei.com> Date: Thu, 08 Dec 2016 14:50:56 +1300 In-Reply-To: <1481116631-33527-1-git-send-email-zhongjiang@huawei.com> (zhongjiang@huawei.com's message of "Wed, 7 Dec 2016 21:17:11 +0800") Message-ID: <87k2bbchof.fsf@xmission.com> MIME-Version: 1.0 Subject: Re: [PATCH] kexec: add cond_resched into kimage_alloc_crash_control_pages List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: zhongjiang Cc: akpm@linux-foundation.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org zhongjiang writes: > From: zhong jiang > > A soft lookup will occur when I run trinity in syscall kexec_load. > the corresponding stack information is as follows. Overall that looks reasonable. Why only every 256 page and not call cond_resched unconditionally? The function cond_resched won't reschedule unless the process has spent it's cpu quota anyway. Eric > [ 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 | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c > index 5616755..2b43cc5 100644 > --- a/kernel/kexec_core.c > +++ b/kernel/kexec_core.c > @@ -433,6 +433,7 @@ static struct page *kimage_alloc_crash_control_pages(struct kimage *image, > */ > unsigned long hole_start, hole_end, size; > struct page *pages; > + unsigned long count = 0; > > pages = NULL; > size = (1 << order) << PAGE_SHIFT; > @@ -441,6 +442,9 @@ static struct page *kimage_alloc_crash_control_pages(struct kimage *image, > while (hole_end <= crashk_res.end) { > unsigned long i; > > + if (++count % 256 == 0) > + cond_resched(); > + > if (hole_end > KEXEC_CRASH_CONTROL_MEMORY_LIMIT) > break; > /* See if I overlap any of the segments */ _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933853AbcLHByA (ORCPT ); Wed, 7 Dec 2016 20:54:00 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:34267 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752481AbcLHBx7 (ORCPT ); Wed, 7 Dec 2016 20:53:59 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: zhongjiang Cc: , , References: <1481116631-33527-1-git-send-email-zhongjiang@huawei.com> Date: Thu, 08 Dec 2016 14:50:56 +1300 In-Reply-To: <1481116631-33527-1-git-send-email-zhongjiang@huawei.com> (zhongjiang@huawei.com's message of "Wed, 7 Dec 2016 21:17:11 +0800") Message-ID: <87k2bbchof.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1cEnuB-0000ti-DF;;;mid=<87k2bbchof.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=101.100.131.98;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18tKlHCZ9VV0OKNGNz/e6k23J/VI7Dz7so= X-SA-Exim-Connect-IP: 101.100.131.98 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.5 XMGappySubj_01 Very gappy subject * 1.0 XMGappySubj_02 Gappier still * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 1.2 LotsOfNums_01 BODY: Lots of long strings of numbers * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.1 XM_H_SpoofStaff3 XMission Staff Spoof X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;zhongjiang X-Spam-Relay-Country: X-Spam-Timing: total 5540 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 3.3 (0.1%), b_tie_ro: 2.4 (0.0%), parse: 0.76 (0.0%), extract_message_metadata: 11 (0.2%), get_uri_detail_list: 1.88 (0.0%), tests_pri_-1000: 4.5 (0.1%), tests_pri_-950: 1.13 (0.0%), tests_pri_-900: 0.97 (0.0%), tests_pri_-400: 25 (0.4%), check_bayes: 24 (0.4%), b_tokenize: 7 (0.1%), b_tok_get_all: 8 (0.1%), b_comp_prob: 2.0 (0.0%), b_tok_touch_all: 3.5 (0.1%), b_finish: 0.74 (0.0%), tests_pri_0: 286 (5.2%), check_dkim_signature: 0.47 (0.0%), check_dkim_adsp: 2.9 (0.1%), tests_pri_500: 5204 (93.9%), poll_dns_idle: 5197 (93.8%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] kexec: add cond_resched into kimage_alloc_crash_control_pages X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org zhongjiang writes: > From: zhong jiang > > A soft lookup will occur when I run trinity in syscall kexec_load. > the corresponding stack information is as follows. Overall that looks reasonable. Why only every 256 page and not call cond_resched unconditionally? The function cond_resched won't reschedule unless the process has spent it's cpu quota anyway. Eric > [ 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 | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c > index 5616755..2b43cc5 100644 > --- a/kernel/kexec_core.c > +++ b/kernel/kexec_core.c > @@ -433,6 +433,7 @@ static struct page *kimage_alloc_crash_control_pages(struct kimage *image, > */ > unsigned long hole_start, hole_end, size; > struct page *pages; > + unsigned long count = 0; > > pages = NULL; > size = (1 << order) << PAGE_SHIFT; > @@ -441,6 +442,9 @@ static struct page *kimage_alloc_crash_control_pages(struct kimage *image, > while (hole_end <= crashk_res.end) { > unsigned long i; > > + if (++count % 256 == 0) > + cond_resched(); > + > if (hole_end > KEXEC_CRASH_CONTROL_MEMORY_LIMIT) > break; > /* See if I overlap any of the segments */