From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C77FAC433DB for ; Wed, 3 Feb 2021 13:06:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 91E1360203 for ; Wed, 3 Feb 2021 13:06:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231487AbhBCNGR convert rfc822-to-8bit (ORCPT ); Wed, 3 Feb 2021 08:06:17 -0500 Received: from out30-54.freemail.mail.aliyun.com ([115.124.30.54]:33942 "EHLO out30-54.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231178AbhBCNGQ (ORCPT ); Wed, 3 Feb 2021 08:06:16 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R631e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=alimailimapcm10staff010182156082;MF=chenshiyan@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0UNm4EsP_1612357445; Received: from 30.39.162.59(mailfrom:chenshiyan@linux.alibaba.com fp:SMTPD_---0UNm4EsP_1612357445) by smtp.aliyun-inc.com(127.0.0.1); Wed, 03 Feb 2021 21:04:06 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [PATCH RESEND] nohz: Restart tick before do softirq From: chenshiyan In-Reply-To: <20210201123811.GA41955@lothringen> Date: Wed, 3 Feb 2021 21:04:05 +0800 Cc: fweisbec@gmail.com, tglx@linutronix.de, mingo@kernel.org, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: References: <1612151143-72242-1-git-send-email-chenshiyan@linux.alibaba.com> <20210201123811.GA41955@lothringen> To: Frederic Weisbecker X-Mailer: Apple Mail (2.3608.80.23.2.2) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Frederic, Thanks for replying. Let’s try to clarify: > On Mon, Feb 01, 2021 at 11:45:43AM +0800, chenshiyan wrote: >> When the cpu is continuously idle, tick_irq_exit() will count next tick >> expiry > > What do you mean by counting next tick expiry here? Is is when > tick_nohz_full_update_tick() reprogramms the next tick? Yes, tick_nohz_full_update_tick() will reprograms the next tick. > >> with maybe several periodic ticks > > you mean that perhaps it's not going to stop it right now? > I mean after reprogramming, maybe next tick will come in a long time . That’s normal and the problem is not here. > >> but if it enters softirq before next tick > > Not sure what you mean here. In irq_exit(), it may do softirq handlings for long time, and during that time, there’s no ticks. That’s the problem. > >> invoke_softirq() is called before tick_irq_exit(), >> there will be no ticks during softirq. > > Ok the issue happens when an IRQ fires while the tick is stopped, right? Right. > > >> So with sched_clock_irqtime >> closing, sirq is very low in nohz idle even if the softirq costs much >> time beause of the sampling ticks missing(sirq will be much higher and >> seem exact if the cpu is busy). > > But this only happens when sched_clock() is based on jiffies, right? > Are you working on an architecture that doesn't implement it? But this only happens when sched_clock() is based on jiffies, right? -More specifically, this only happens when CONFIG_IRQ_TIME_ACCOUNTING is close. As above say, there’s no ticks during softirq, so we can’t count how long it takes. Are you working on an architecture that doesn't implement it? -No, we test it on x86. The problem is , when it's doing softirq, but there’s no tick, so we don’t know how long It takes. The TOP or some other procs can not show the right value of sirq. This patch tries to restart tick before softirq. So far it works and we get an accurate value of sirq. Maybe it’s not the best way to solve this problem and hope you would like to help me. Thanks. > 2021年2月1日 下午8:38，Frederic Weisbecker 写道： > > Hi, > > I'm a bit confused with the changelog, let's try to clarify: > > On Mon, Feb 01, 2021 at 11:45:43AM +0800, chenshiyan wrote: >> When the cpu is continuously idle, tick_irq_exit() will count next tick >> expiry > > What do you mean by counting next tick expiry here? Is is when > tick_nohz_full_update_tick() reprogramms the next tick? > >> with maybe several periodic ticks > > you mean that perhaps it's not going to stop it right now? > > >> but if it enters softirq before next tick > > Not sure what you mean here. > >> invoke_softirq() is called before tick_irq_exit(), >> there will be no ticks during softirq. > > Ok the issue happens when an IRQ fires while the tick is stopped, right? > > >> So with sched_clock_irqtime >> closing, sirq is very low in nohz idle even if the softirq costs much >> time beause of the sampling ticks missing(sirq will be much higher and >> seem exact if the cpu is busy). > > But this only happens when sched_clock() is based on jiffies, right? > Are you working on an architecture that doesn't implement it? > > Thanks. > >> >> Signed-off-by: chenshiyan >> --- >> kernel/softirq.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/kernel/softirq.c b/kernel/softirq.c >> index 9d71046..8f3f71b9 100644 >> --- a/kernel/softirq.c >> +++ b/kernel/softirq.c >> @@ -210,6 +210,7 @@ static inline void invoke_softirq(void) >> return; >> >> if (!force_irqthreads) { >> + tick_nohz_idle_restart_tick(); >> #ifdef CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK >> /* >> * We can safely execute softirq on the current stack if >> -- >> 1.8.3.1