Messages in this thread | | | From | "Perez-Gonzalez, Inaky" <> | Subject | RE: O(1) scheduler seems to lock up on sched_FIFO and sched_RR ta sks | Date | Thu, 19 Jun 2003 12:22:13 -0700 |
| |
> From: Robert Love [mailto:rml@tech9.net] > > 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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |