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=-10.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 E0BB6C4741F for ; Thu, 1 Oct 2020 14:44:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9F2992158C for ; Thu, 1 Oct 2020 14:44:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601563498; bh=dDC26q515F+Adnjw4FlkjfdULIOBLB9BDdSe3RhWuDU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=jJ7JlWyPt13x7+syyOD/sSZ4hjZsO1N+ASxuN/cEgMbSqsC1U1xDIg4r1k1ufbndn aA83HAqaxhOsRmTs4YVnZKr3UMgy3LtxaHBKkfWBYhvednazuXljcWLaPCEsKPRyzL 4Ub7RY+p60TjUU67BHrB9HAxtBIx4/ams6dQjpYI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732482AbgJAOo6 (ORCPT ); Thu, 1 Oct 2020 10:44:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:60730 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732020AbgJAOo5 (ORCPT ); Thu, 1 Oct 2020 10:44:57 -0400 Received: from localhost (fla63-h02-176-172-189-251.dsl.sta.abo.bbox.fr [176.172.189.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7CE5E207FB; Thu, 1 Oct 2020 14:44:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601563497; bh=dDC26q515F+Adnjw4FlkjfdULIOBLB9BDdSe3RhWuDU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=F3NVYP8tZU/Bi6llA5AaYGUeVhjR70aMs4gOeqYxm3k+PAJeYZ02dTbkx0lAK0kW+ G4oJv2DEjiAPRuxOp5vVP8gFXBP061GqDAJpK9vy08WczDaCm5fp77iUrSaZkwEqVv b6CtDaGlsU+Y48auonfo+Dsndbl96Q/J+bNpG4CY= Date: Thu, 1 Oct 2020 16:44:54 +0200 From: Frederic Weisbecker To: Alex Belits Cc: "rostedt@goodmis.org" , Prasun Kapoor , "mingo@kernel.org" , "davem@davemloft.net" , "linux-api@vger.kernel.org" , "peterz@infradead.org" , "linux-arch@vger.kernel.org" , "catalin.marinas@arm.com" , "tglx@linutronix.de" , "will@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" Subject: Re: [PATCH v4 10/13] task_isolation: don't interrupt CPUs with tick_nohz_full_kick_cpu() Message-ID: <20201001144454.GB6595@lothringen> References: <04be044c1bcd76b7438b7563edc35383417f12c8.camel@marvell.com> <5acf7502c071c0d1365ba5e5940e003a7da6521f.camel@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5acf7502c071c0d1365ba5e5940e003a7da6521f.camel@marvell.com> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Jul 22, 2020 at 02:57:33PM +0000, Alex Belits wrote: > From: Yuri Norov > > For nohz_full CPUs the desirable behavior is to receive interrupts > generated by tick_nohz_full_kick_cpu(). But for hard isolation it's > obviously not desirable because it breaks isolation. > > This patch adds check for it. > > Signed-off-by: Yuri Norov > [abelits@marvell.com: updated, only exclude CPUs running isolated tasks] > Signed-off-by: Alex Belits > --- > kernel/time/tick-sched.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c > index 6e4cd8459f05..2f82a6daf8fc 100644 > --- a/kernel/time/tick-sched.c > +++ b/kernel/time/tick-sched.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -268,7 +269,8 @@ static void tick_nohz_full_kick(void) > */ > void tick_nohz_full_kick_cpu(int cpu) > { > - if (!tick_nohz_full_cpu(cpu)) > + smp_rmb(); What is it ordering? > + if (!tick_nohz_full_cpu(cpu) || task_isolation_on_cpu(cpu)) > return; You can't simply ignore an IPI. There is always a reason for a nohz_full CPU to be kicked. Something triggered a tick dependency. It can be posix cpu timers for example, or anything. > > irq_work_queue_on(&per_cpu(nohz_full_kick_work, cpu), cpu); > -- > 2.26.2 >