From: Valentin Schneider <valentin.schneider@arm.com> To: peterz@infradead.org Cc: Thomas Gleixner <tglx@linutronix.de>, 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: Wed, 05 Aug 2020 14:56:49 +0100 [thread overview] Message-ID: <jhja6z9i4bi.mognet@arm.com> (raw) In-Reply-To: <20200805134002.GQ2674@hirez.programming.kicks-ass.net> On 05/08/20 14:40, peterz@infradead.org wrote: > 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. > I'm starting to think that as well. I tried some fugly hack of injecting avg_irq into sched_rt_runtime_exceeded() with something along the lines of: irq_time = (rq->avg_irq.util_avg * sched_rt_period(rt_rq)) >> SCHED_CAPACITY_SHIFT; It's pretty bad for a few reasons; one is that avg_irq already has its own period (PELT-based). Another is that it is, as Dietmar pointed out, CPU and freq invariant, so falls over on big.LITTLE. Making update_curr_rt() use rq_clock() rather than rq_clock_task() makes it "work" but goes against all the good reasons there were to introduce rq_clock_task() in the first place. > 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. 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.
WARNING: multiple messages have this Message-ID (diff)
From: Valentin Schneider <valentin.schneider@arm.com> 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>, Thomas Gleixner <tglx@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: Wed, 05 Aug 2020 14:56:49 +0100 [thread overview] Message-ID: <jhja6z9i4bi.mognet@arm.com> (raw) In-Reply-To: <20200805134002.GQ2674@hirez.programming.kicks-ass.net> On 05/08/20 14:40, peterz@infradead.org wrote: > 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. > I'm starting to think that as well. I tried some fugly hack of injecting avg_irq into sched_rt_runtime_exceeded() with something along the lines of: irq_time = (rq->avg_irq.util_avg * sched_rt_period(rt_rq)) >> SCHED_CAPACITY_SHIFT; It's pretty bad for a few reasons; one is that avg_irq already has its own period (PELT-based). Another is that it is, as Dietmar pointed out, CPU and freq invariant, so falls over on big.LITTLE. Making update_curr_rt() use rq_clock() rather than rq_clock_task() makes it "work" but goes against all the good reasons there were to introduce rq_clock_task() in the first place. > 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. 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-08-05 20:14 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 [this message] 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 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=jhja6z9i4bi.mognet@arm.com \ --to=valentin.schneider@arm.com \ --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=tglx@linutronix.de \ --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: linkBe 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.