[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200803114112.mrcuupz4ir5uqlp6@skbuf>
Date: Mon, 3 Aug 2020 14:41:12 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Kurt Kanzenbach <kurt.kanzenbach@...utronix.de>,
Alison Wang <alison.wang@....com>, catalin.marinas@....com,
will@...nel.org, paulmck@...nel.org, mw@...ihalf.com,
leoyang.li@....com, vladimir.oltean@....com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Anna-Maria Gleixner <anna-maria@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC PATCH] arm64: defconfig: Disable fine-grained task level
IRQ time accounting
Hi Thomas,
On Mon, Aug 03, 2020 at 12:49:36PM +0200, Thomas Gleixner wrote:
> Kurt,
>
> Kurt Kanzenbach <kurt.kanzenbach@...utronix.de> writes:
> > On Thu Jul 30 2020, Vladimir Oltean wrote:
> > OK. I've reproduced it on a Marvell Armada SoC with v5.6 mainline. See
> > splats below. Running with irq time accounting enabled, kills the
> > machine immediately. However, I'm not getting the possible deadlock
> > warnings in 8250 as you did. So that might be unrelated.
> >
> > Unfortunately I have no idea what to debug here.
>
> lets look at the facts we have so far.
>
> 1) When irq accounting is disabled, RT throttling kicks in as
> expected.
>
> 2) With irq accounting the RT throttler does not kick in and the RCU
> stall/lockups happen.
>
> Not much, but there is clearly interaction between irq time accounting
> and scheduler accounting.
>
> Can you please reduce /proc/sys/kernel/sched_rt_runtime_us in steps of
> 50000? At least in theory, reduction should bring the throttling back.
>
> Thanks,
>
> tglx
>
We already know from my original report that reducing
sched_rt_runtime_us to 80% (800000) gives us a stable system.
https://lkml.org/lkml/2020/6/4/1062
What is this telling us?
Thanks,
-Vladimir
Powered by blists - more mailing lists