On Thu, Aug 06, 2020 at 09:03:24PM +0200, Thomas Gleixner wrote:
> Paul,
>
> "Paul E. McKenney" writes:
> > On Thu, Aug 06, 2020 at 01:45:45PM +0200, pet...@infradead.org wrote:
> >> The safety thing is concerned with RT tasks. It doesn't pretend to help
> >> with runnaway IRQs, never has, never
Paul,
"Paul E. McKenney" writes:
> On Thu, Aug 06, 2020 at 01:45:45PM +0200, pet...@infradead.org wrote:
>> The safety thing is concerned with RT tasks. It doesn't pretend to help
>> with runnaway IRQs, never has, never will.
>
> Getting into the time machine back to the 1990s...
>
> DYNIX/ptx ha
Peter,
pet...@infradead.org writes:
> On Thu, Aug 06, 2020 at 11:41:06AM +0200, Thomas Gleixner wrote:
>> 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 confi
On Thu, Aug 06, 2020 at 01:45:45PM +0200, pet...@infradead.org wrote:
> On Thu, Aug 06, 2020 at 11:41:06AM +0200, Thomas Gleixner wrote:
> > pet...@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
On Thu, Aug 06, 2020 at 11:41:06AM +0200, Thomas Gleixner wrote:
> pet...@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 s
pet...@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
pet...@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 o
On 05/08/20 14:40, pet...@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 wh
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
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 i
On 04/08/2020 01:59, Valentin Schneider wrote:
>
> On 03/08/20 20:22, Thomas Gleixner wrote:
>> Valentin,
>>
>> Valentin Schneider writes:
>>> On 03/08/20 16:13, Thomas Gleixner wrote:
Vladimir Oltean writes:
>> 1) When irq accounting is disabled, RT throttling kicks in as
>> e
On 03/08/20 20:22, Thomas Gleixner wrote:
> Valentin,
>
> Valentin Schneider writes:
>> On 03/08/20 16:13, Thomas Gleixner wrote:
>>> Vladimir Oltean writes:
> 1) When irq accounting is disabled, RT throttling kicks in as
> expected.
>
> 2) With irq accounting the RT throt
Valentin,
Valentin Schneider writes:
> On 03/08/20 16:13, Thomas Gleixner wrote:
>> Vladimir Oltean writes:
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/locku
On Mon, Aug 03, 2020 at 04:47:03PM +0100, Valentin Schneider wrote:
>
> On 03/08/20 16:13, Thomas Gleixner wrote:
> > Vladimir Oltean writes:
> >>> 1) When irq accounting is disabled, RT throttling kicks in as
> >>> expected.
> >>>
> >>> 2) With irq accounting the RT throttler does not kic
On 03/08/20 16:13, Thomas Gleixner wrote:
> Vladimir Oltean writes:
>>> 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.
>> What is this telling us?
>
> It
Vladimir Oltean writes:
>> 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
On 2020-08-03 12:48, Valentin Schneider wrote:
On 03/08/20 12:38, Vladimir Oltean wrote:
On Mon, Aug 03, 2020 at 10:51:32AM +0100, Robin Murphy wrote:
Having glanced across another thread that mentions IRQ accounting
recently[1], I wonder if the underlying bug here might have something
do to
On 03/08/20 12:38, Vladimir Oltean wrote:
> On Mon, Aug 03, 2020 at 10:51:32AM +0100, Robin Murphy wrote:
>>
>> Having glanced across another thread that mentions IRQ accounting
>> recently[1], I wonder if the underlying bug here might have something do to
>> with the stuff that Marc's trying to
Hi Thomas,
On Mon, Aug 03, 2020 at 12:49:36PM +0200, Thomas Gleixner wrote:
> Kurt,
>
> Kurt Kanzenbach 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, ki
On Mon, Aug 03, 2020 at 10:51:32AM +0100, Robin Murphy wrote:
>
> Having glanced across another thread that mentions IRQ accounting
> recently[1], I wonder if the underlying bug here might have something do to
> with the stuff that Marc's trying to clean up.
>
> Robin.
>
> [1]
> https://lore.ke
Kurt,
Kurt Kanzenbach 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
Vladimir Oltean writes:
> On Mon, Aug 03, 2020 at 10:04:01AM +0200, Kurt Kanzenbach wrote:
>> Unfortunately I have no idea what to debug here.
>
> So, this means we could submit a formal version of this patch? :)
To paper over the underlying problem. Oh well...
On 2020-08-03 09:16, Vladimir Oltean wrote:
On Mon, Aug 03, 2020 at 10:04:01AM +0200, Kurt Kanzenbach wrote:
On Thu Jul 30 2020, Vladimir Oltean wrote:
On Thu, Jul 30, 2020 at 09:23:44AM +0200, Kurt Kanzenbach wrote:
On Wed Jul 29 2020, Vladimir Oltean wrote:
For more context, here is my orig
On Mon, Aug 03, 2020 at 10:04:01AM +0200, Kurt Kanzenbach wrote:
> On Thu Jul 30 2020, Vladimir Oltean wrote:
> > On Thu, Jul 30, 2020 at 09:23:44AM +0200, Kurt Kanzenbach wrote:
> >> On Wed Jul 29 2020, Vladimir Oltean wrote:
> >> > For more context, here is my original report of the issue:
> >> >
On Thu Jul 30 2020, Vladimir Oltean wrote:
> On Thu, Jul 30, 2020 at 09:23:44AM +0200, Kurt Kanzenbach wrote:
>> On Wed Jul 29 2020, Vladimir Oltean wrote:
>> > For more context, here is my original report of the issue:
>> > https://lkml.org/lkml/2020/6/4/1062
>> >
>> > Just like you, I could not r
On Thu, Jul 30, 2020 at 09:23:44AM +0200, Kurt Kanzenbach wrote:
> Hi Vladimir,
>
> On Wed Jul 29 2020, Vladimir Oltean wrote:
> > For more context, here is my original report of the issue:
> > https://lkml.org/lkml/2020/6/4/1062
> >
> > Just like you, I could not reproduce the RCU stalls and syst
Hi Vladimir,
On Wed Jul 29 2020, Vladimir Oltean wrote:
> For more context, here is my original report of the issue:
> https://lkml.org/lkml/2020/6/4/1062
>
> Just like you, I could not reproduce the RCU stalls and system hang on a
> 5.6-rt kernel, just on mainline and derivatives, using the plain
On Wed, Jul 29, 2020 at 10:40:29AM +0200, Kurt Kanzenbach wrote:
> Hi Alison,
>
> On Wed Jul 29 2020, Alison Wang wrote:
> > In the current arm64 defconfig, CONFIG_IRQ_TIME_ACCOUNTING is enabled as
> > default. According to my tests on NXP's LayerScape and i.MX platforms,
> > the system hangs when
Hi, Kurt,
> On Wed Jul 29 2020, Alison Wang wrote:
> > In the current arm64 defconfig, CONFIG_IRQ_TIME_ACCOUNTING is enabled
> > as default. According to my tests on NXP's LayerScape and i.MX
> > platforms, the system hangs when running the command "stress-ng
> > --hrtimers 1" with CONFIG_IRQ_TIME
Hi Alison,
On Wed Jul 29 2020, Alison Wang wrote:
> In the current arm64 defconfig, CONFIG_IRQ_TIME_ACCOUNTING is enabled as
> default. According to my tests on NXP's LayerScape and i.MX platforms,
> the system hangs when running the command "stress-ng --hrtimers 1" with
> CONFIG_IRQ_TIME_ACCOUNTI
In the current arm64 defconfig, CONFIG_IRQ_TIME_ACCOUNTING is enabled as
default. According to my tests on NXP's LayerScape and i.MX platforms,
the system hangs when running the command "stress-ng --hrtimers 1" with
CONFIG_IRQ_TIME_ACCOUNTING enabled. Disabling this option, the issue
disappears. CO
31 matches
Mail list logo
