From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frederic Weisbecker Subject: Re: [PATCH 08/12] task_isolation: don't interrupt CPUs with tick_nohz_full_kick_cpu() Date: Fri, 6 Mar 2020 17:03:42 +0100 Message-ID: <20200306160341.GE8590@lenoir> References: <4473787e1b6bc3cc226067e8d122092a678b63de.camel@marvell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Alex Belits Cc: "rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org" , "mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" , "peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Prasun Kapoor , "tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org" , "linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-mm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-arch.vger.kernel.org On Wed, Mar 04, 2020 at 04:12:40PM +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: Alex Belits > --- > kernel/time/tick-sched.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c > index 1d4dec9d3ee7..fe4503ba1316 100644 > --- a/kernel/time/tick-sched.c > +++ b/kernel/time/tick-sched.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -262,7 +263,7 @@ static void tick_nohz_full_kick(void) > */ > void tick_nohz_full_kick_cpu(int cpu) > { > - if (!tick_nohz_full_cpu(cpu)) > + if (!tick_nohz_full_cpu(cpu) || task_isolation_on_cpu(cpu)) > return; I fear you can't do that. A nohz full CPU is kicked for a reason. As for the other cases, you need to fix the callers. In the general case, randomly ignoring an interrupt is a correctness issue. Thanks. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org ([198.145.29.99]:38712 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725935AbgCFQDp (ORCPT ); Fri, 6 Mar 2020 11:03:45 -0500 Date: Fri, 6 Mar 2020 17:03:42 +0100 From: Frederic Weisbecker Subject: Re: [PATCH 08/12] task_isolation: don't interrupt CPUs with tick_nohz_full_kick_cpu() Message-ID: <20200306160341.GE8590@lenoir> References: <4473787e1b6bc3cc226067e8d122092a678b63de.camel@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Alex Belits Cc: "rostedt@goodmis.org" , "mingo@kernel.org" , "peterz@infradead.org" , "linux-kernel@vger.kernel.org" , Prasun Kapoor , "tglx@linutronix.de" , "linux-api@vger.kernel.org" , "linux-mm@vger.kernel.org" , "linux-arch@vger.kernel.org" Message-ID: <20200306160342.A8woeTv5E2rVYtC03GbJ875uknvEEbybaW-iPecO0y8@z> On Wed, Mar 04, 2020 at 04:12:40PM +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: Alex Belits > --- > kernel/time/tick-sched.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c > index 1d4dec9d3ee7..fe4503ba1316 100644 > --- a/kernel/time/tick-sched.c > +++ b/kernel/time/tick-sched.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -262,7 +263,7 @@ static void tick_nohz_full_kick(void) > */ > void tick_nohz_full_kick_cpu(int cpu) > { > - if (!tick_nohz_full_cpu(cpu)) > + if (!tick_nohz_full_cpu(cpu) || task_isolation_on_cpu(cpu)) > return; I fear you can't do that. A nohz full CPU is kicked for a reason. As for the other cases, you need to fix the callers. In the general case, randomly ignoring an interrupt is a correctness issue. Thanks.