Re: [PATCH 16/23] sched,watchdog: Convert to sched_set_fifo()

[Christophe Leroy]

Hi Peter,

Le 22/04/2020 à 15:24, Peter Zijlstra a écrit :
> On Wed, Apr 22, 2020 at 08:51:55AM -0400, Steven Rostedt wrote:
> > On Wed, 22 Apr 2020 13:27:35 +0200
> > Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >
> > > Because SCHED_FIFO is a broken scheduler model (see previous patches)
> > > take away the priority field, the kernel can't possibly make an
> > > informed decision.
> > >
> > > Effectively changes prio from 99 to 50.
> >
> > Hmm, this being a watchdog, and looking at commit 38a1222ae4f364d
> > ("watchdog: core: make sure the watchdog worker always works")
> >
> > I wonder if we should add a sched_set_high(), or have some other kind of
> > watchdog handler that is guaranteed to trigger.
>
> It's FIFO, it'll never win from either a deadline or a stop-task. After
> that it doesn't matter.

It does matter. I didn't realise it when you sent out this patch five 
years ago, but today I'm facing an issue due to that patch. On powerpc 
8xx the watchdog must be woken up every second, the HW is not able to 
take a higher timeout. I have process that is running at SCHED_FIFO prio 
90. From time to time it keeps running for a bit more than one second, 
leading to a watchdog reset. This didn't happen before your patch.

Why having arbitrary selected prio 50 and not kept it at the highest 
possible priority ?

What would be the solution to fix this unexpected watchdog reset ?

> fifo_high() is most definitely a bad idea, because then we're back into
> the whole 'fifo priority' has meaning -- it does not. At least, it
> doesn't until you've got system design information.

I don't understand why it has no meaning. When I have a user app at FIFO 
prio 90 and one at FIFO 89 I know the one at 90 will immediatly preempt 
the one at 89 when receiving data, and that's the behaviour I expect. 
What am I missing here ?

Christophe