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

[Perez-Gonzalez, Inaky]

> From: Robert Love [mailto:[e-mail]]
> 
> And we can prevent starvation just by running the kernel thread at
> FIFO/99, because then it will never be starved by a higher priority
> task. If the RT task being starved is also at priority 99, it will
> eventually block (as in our example, on console I/O) and let the kernel
> thread run. If the RT task being starved is lower priority, then there
> is nothing to worry about.

/me is quite uneasy with that assumption; not that it is not
correct (it should), but I can think of cases where that does 
not need to happen (for example, if you have another FIFO/99 
task B after your user task A that depends on kernel task K0),
and that task B happens to hold it for too long for A to miss
deadlines.

> I guess a real deadlock could only occur if the FIFO/99 task does not
> block on the resource the kernel thread is providing but busy loops
> waiting for it.

I can think of a OpenOffice + sched_yield() style or a brain-damaged 
poll for previous art. It would screw the whole equation.

Another example, I changed NGPT to do spin+futex for spinlocks, 
but then it was changed back by someone to spinning again -- 
performance reasons [they said] - of course, Thou Shall Not 
Use NGPT + Real-Time (tm). But how many of these are left? I am
so scared of JVMs...

This is even more prone to happen when you have priority
inheritance ... been there, done that, SysRq+E was my friend. 

It gets uncomfortably close to the "not my problem if you don't 
know to set up your system" area, but I would really prefer that
safeguard that then I can disable manually (by prioritizing down)
if I know where to push.

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