Re: O(1) scheduler seems to lock up on sched_FIFO and sched_RR tasks

[Andrew Morton <akpm@digeo.com>]

george anzinger <george@mvista.com> wrote:
>
> Joe Korty wrote:
> > On Wed, Jun 18, 2003 at 09:47:24AM -0700, george anzinger wrote:
> > 
> >>It seems that once a SCHED_FIFO or SCHED_RR tasks gets control it does 
> >>not yield to other tasks of higher priority.
> >>
> >>Attached is a test program (busyloop) that just loops doing 
> >>gettimeofday() for the requested time and a little utility (rt) to run 
> >>programs at real time priorities.
> >>
> >>Here is an annotated example of the problem:
> >>
> >>First, become root then:
> >>
> >>>rt 90 bash        <-- run bash at priority 90 SCHED_RR
> >>>rt -f 30 busyloop 10 &  <-- busyloop 10 at priority 30 SCHED_FIFO
> >>
> >>At this point the bash at priority 90 should be available, but is not. 
> >> When the 10 second busyloop completes, bash returns.
> > 
> > 
> > 
> > Hi George,
> >  When I boost the priority of each of the per-cpu 'events/%d' daemon to
> > 96, the problem goes away.
> 
> Seems like your saying that the events workqueues are involved in the 
> scheduler in some ugly way.  Certainly not what your average rt 
> programmer would expect :(  What is going on here?
> 

Various things like character drivers do rely upon keventd services.  So it
is possible that bash is stuck waiting on keyboard input, but there is no
keyboard input because keventd is locked out.

I'll take a closer look at this, see if there is a specific case which can
be fixed.

Arguably, keventd should be running max-prio RT because it is a kernel
service, providing "process context interrupt service".

IIRC, Andrea's kernel runs keventd as SCHED_FIFO.  I've tried to avoid
making this change for ideological reasons ;) Userspace is more important
than the kernel and the kernel has no damn right to be saying "oh my stuff
is so important that it should run before latency-critical user code".

Tricky.