lkml.org 
[lkml]   [2003]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: O(1) scheduler seems to lock up on sched_FIFO and sched_RR ta sks
Date

> 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/

\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.015 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site