All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: peterz@infradead.org
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, Valentin Schneider <valentin.schneider@arm.com>,
	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:34:42 +0200	[thread overview]
Message-ID: <877duci0ct.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200805134002.GQ2674@hirez.programming.kicks-ass.net>

peterz@infradead.org writes:
> On Mon, Aug 03, 2020 at 09:22:53PM +0200, Thomas Gleixner wrote:
>
>>    totaltime = irqtime + tasktime
>> 
>> Ignoring irqtime and pretending that totaltime is what the scheduler
>> can control and deal with is naive at best.
>
> Well no, that's what we call system overhead and is assumed to be
> included in the 'error margin'.
>
> The way things are set up is that we say that, by default, RT tasks can
> consume 95% of cputime and the remaining 5% is sufficient to keep the
> system alive.
>
> Those 5% include all system overhead, IRQs, RCU, !RT workqueues etc..
>
> Obviously IRQ_TIME accounting changes the balance a bit, but that's what
> it is. We can't really do anything better.
>
> Apparently this SoC has significant IRQ time for some reason. Also,
> relying on RT throttling for 'correct' behaviour is also wrong. What
> needs to be done is find who is using all this RT time and why, that
> isn't right.

It's a test case and we know already who is using the time. But that's
not the point.

A runaway RT task resulting in a RCU stall or whatever lockup of the
system is definitely not the right answer.

The throttler, as much as it's a horrible hack, is there to prevent this
and to give the admin a chance to pinpoint and kill that thing instead
of having to press the reset button and scratching head what might have
caused this.

Thanks,

        tglx

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

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: peterz@infradead.org
Cc: Valentin Schneider <valentin.schneider@arm.com>,
	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:34:42 +0200	[thread overview]
Message-ID: <877duci0ct.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200805134002.GQ2674@hirez.programming.kicks-ass.net>

peterz@infradead.org writes:
> On Mon, Aug 03, 2020 at 09:22:53PM +0200, Thomas Gleixner wrote:
>
>>    totaltime = irqtime + tasktime
>> 
>> Ignoring irqtime and pretending that totaltime is what the scheduler
>> can control and deal with is naive at best.
>
> Well no, that's what we call system overhead and is assumed to be
> included in the 'error margin'.
>
> The way things are set up is that we say that, by default, RT tasks can
> consume 95% of cputime and the remaining 5% is sufficient to keep the
> system alive.
>
> Those 5% include all system overhead, IRQs, RCU, !RT workqueues etc..
>
> Obviously IRQ_TIME accounting changes the balance a bit, but that's what
> it is. We can't really do anything better.
>
> Apparently this SoC has significant IRQ time for some reason. Also,
> relying on RT throttling for 'correct' behaviour is also wrong. What
> needs to be done is find who is using all this RT time and why, that
> isn't right.

It's a test case and we know already who is using the time. But that's
not the point.

A runaway RT task resulting in a RCU stall or whatever lockup of the
system is definitely not the right answer.

The throttler, as much as it's a horrible hack, is there to prevent this
and to give the admin a chance to pinpoint and kill that thing instead
of having to press the reset button and scratching head what might have
caused this.

Thanks,

        tglx

  parent reply	other threads:[~2020-08-06 12:18 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
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 [this message]
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=877duci0ct.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.