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
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
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
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
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
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
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
>>
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
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
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
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?
>
>
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
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,
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]
>
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
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
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
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
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
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
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
>
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.
31 matches
Mail list logo
