All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: peterz@infradead.org, Valentin Schneider <valentin.schneider@arm.com>
Cc: Vladimir Oltean <olteanv@gmail.com>,
	Kurt Kanzenbach <kurt.kanzenbach@linutronix.de>,
	Alison Wang <alison.wang@nxp.com>,
	catalin.marinas@arm.com, will@kernel.org, paulmck@kernel.org,
	mw@semihalf.com, leoyang.li@nxp.com, vladimir.oltean@nxp.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Anna-Maria Gleixner <anna-maria@linutronix.de>
Subject: Re: [RFC PATCH] arm64: defconfig: Disable fine-grained task level IRQ time accounting
Date: Thu, 06 Aug 2020 11:41:06 +0200	[thread overview]
Message-ID: <874kpgi025.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200805153120.GU2674@hirez.programming.kicks-ass.net>

peterz@infradead.org writes:
> On Wed, Aug 05, 2020 at 02:56:49PM +0100, Valentin Schneider wrote:
>
>> I've been tempted to say the test case is a bit bogus, but am not familiar
>> enough with the RT throttling details to stand that ground. That said, from
>> both looking at the execution and the stress-ng source code, it seems to
>> unconditionally spawn 32 FIFO-50 tasks (there's even an option to make
>> these FIFO-99!!!), which is quite a crowd on monoCPU systems.
>
> Oh, so it's a case of: we do stupid without tuning and the system falls
> over. I can live with that.

It's not a question of whether you can live with that behaviour for a
particular silly test case.

The same happens with a single RT runaway task with enough interrupt
load on a UP machine. Just validated that. And that has nothing to do
with a silly test case. Sporadic runaways due to a bug in a once per
week code path simply can happen and having the safety net working
depending on a config option selected or not is just wrong.

Thanks,

        tglx





WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: peterz@infradead.org, Valentin Schneider <valentin.schneider@arm.com>
Cc: mw@semihalf.com, paulmck@kernel.org,
	Anna-Maria Gleixner <anna-maria@linutronix.de>,
	catalin.marinas@arm.com, Alison Wang <alison.wang@nxp.com>,
	linux-kernel@vger.kernel.org, leoyang.li@nxp.com,
	vladimir.oltean@nxp.com,
	Kurt Kanzenbach <kurt.kanzenbach@linutronix.de>,
	Vladimir Oltean <olteanv@gmail.com>,
	will@kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH] arm64: defconfig: Disable fine-grained task level IRQ time accounting
Date: Thu, 06 Aug 2020 11:41:06 +0200	[thread overview]
Message-ID: <874kpgi025.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200805153120.GU2674@hirez.programming.kicks-ass.net>

peterz@infradead.org writes:
> On Wed, Aug 05, 2020 at 02:56:49PM +0100, Valentin Schneider wrote:
>
>> I've been tempted to say the test case is a bit bogus, but am not familiar
>> enough with the RT throttling details to stand that ground. That said, from
>> both looking at the execution and the stress-ng source code, it seems to
>> unconditionally spawn 32 FIFO-50 tasks (there's even an option to make
>> these FIFO-99!!!), which is quite a crowd on monoCPU systems.
>
> Oh, so it's a case of: we do stupid without tuning and the system falls
> over. I can live with that.

It's not a question of whether you can live with that behaviour for a
particular silly test case.

The same happens with a single RT runaway task with enough interrupt
load on a UP machine. Just validated that. And that has nothing to do
with a silly test case. Sporadic runaways due to a bug in a once per
week code path simply can happen and having the safety net working
depending on a config option selected or not is just wrong.

Thanks,

        tglx





_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-08-06 11:13 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-29  3:39 [RFC PATCH] arm64: defconfig: Disable fine-grained task level IRQ time accounting Alison Wang
2020-07-29  3:39 ` Alison Wang
2020-07-29  8:40 ` Kurt Kanzenbach
2020-07-29  8:40   ` Kurt Kanzenbach
2020-07-29  8:50   ` [EXT] " Alison Wang
2020-07-29  8:50     ` Alison Wang
2020-07-29  9:49   ` Vladimir Oltean
2020-07-29  9:49     ` Vladimir Oltean
2020-07-30  7:23     ` Kurt Kanzenbach
2020-07-30  7:23       ` Kurt Kanzenbach
2020-07-30  8:22       ` Vladimir Oltean
2020-07-30  8:22         ` Vladimir Oltean
2020-08-03  8:04         ` Kurt Kanzenbach
2020-08-03  8:04           ` Kurt Kanzenbach
2020-08-03  8:16           ` Vladimir Oltean
2020-08-03  8:16             ` Vladimir Oltean
2020-08-03  9:51             ` Robin Murphy
2020-08-03  9:51               ` Robin Murphy
2020-08-03 11:38               ` Vladimir Oltean
2020-08-03 11:38                 ` Vladimir Oltean
2020-08-03 11:48                 ` Valentin Schneider
2020-08-03 11:48                   ` Valentin Schneider
2020-08-03 13:24                   ` Marc Zyngier
2020-08-03 13:24                     ` Marc Zyngier
2020-08-03 10:02             ` Thomas Gleixner
2020-08-03 10:02               ` Thomas Gleixner
2020-08-03 10:49           ` Thomas Gleixner
2020-08-03 10:49             ` Thomas Gleixner
2020-08-03 11:41             ` Vladimir Oltean
2020-08-03 11:41               ` Vladimir Oltean
2020-08-03 15:13               ` Thomas Gleixner
2020-08-03 15:13                 ` Thomas Gleixner
2020-08-03 15:47                 ` Valentin Schneider
2020-08-03 15:47                   ` Valentin Schneider
2020-08-03 16:14                   ` Vladimir Oltean
2020-08-03 16:14                     ` Vladimir Oltean
2020-08-03 19:22                   ` Thomas Gleixner
2020-08-03 19:22                     ` Thomas Gleixner
2020-08-03 23:59                     ` Valentin Schneider
2020-08-03 23:59                       ` Valentin Schneider
2020-08-05  8:50                       ` Dietmar Eggemann
2020-08-05  8:50                         ` Dietmar Eggemann
2020-08-05 13:40                     ` peterz
2020-08-05 13:40                       ` peterz
2020-08-05 13:56                       ` Valentin Schneider
2020-08-05 13:56                         ` Valentin Schneider
2020-08-05 15:31                         ` peterz
2020-08-05 15:31                           ` peterz
2020-08-06  9:41                           ` Thomas Gleixner [this message]
2020-08-06  9:41                             ` Thomas Gleixner
2020-08-06 11:45                             ` peterz
2020-08-06 11:45                               ` peterz
2020-08-06 13:27                               ` Paul E. McKenney
2020-08-06 13:27                                 ` Paul E. McKenney
2020-08-06 19:03                                 ` Thomas Gleixner
2020-08-06 19:03                                   ` Thomas Gleixner
2020-08-06 20:39                                   ` Paul E. McKenney
2020-08-06 20:39                                     ` Paul E. McKenney
2020-08-06 18:58                               ` Thomas Gleixner
2020-08-06 18:58                                 ` Thomas Gleixner
2020-08-06  9:34                       ` Thomas Gleixner
2020-08-06  9:34                         ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874kpgi025.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=alison.wang@nxp.com \
    --cc=anna-maria@linutronix.de \
    --cc=catalin.marinas@arm.com \
    --cc=kurt.kanzenbach@linutronix.de \
    --cc=leoyang.li@nxp.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mw@semihalf.com \
    --cc=olteanv@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=valentin.schneider@arm.com \
    --cc=vladimir.oltean@nxp.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.