RE: O(1) scheduler seems to lock up on sched_FIFO and sched_RR ta

[Perez-Gonzalez, Inaky]

> From: Andrew Morton [mailto:[e-mail]]
> 
> 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".

Now that we are at that, it might be wise to add a higher-than-anything
priority that the kernel code can use (what would be 100 for user space,
but off-limits), so even FIFO 99 code in user space cannot block out
the migration thread, keventd and friends.

> 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".

I agree with that, but the consequence is kind of ugly; not that a true
real-time embedded process is going to be printing to the console, but 
it might be outputting to a serial line, so now they rely on the keventd.

BTW, I have seen similar problems wrt to the migration thread, where a
FIFO 20 process would get stuck in CPU1, that is taken by a FIFO 40
while CPU0 was running a FIFO 10 -- however, I am not that positive
that it is a migration thread problem; I blame it more on the scheduler
not taking into account priorities for firing the load balancer. It is
a tricky thingie, though. Affinity helps, in this case.

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)