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

From: Perez-Gonzalez, Inaky (inaky.perez-gonzalez@intel.com)
Date: Wed Jun 18 2003 - 21:55:06 EST


> From: george anzinger [mailto:george@mvista.com]
>
> Wait a bit (or even a byte) here. I think the proper thing to do, IF
> we want to go down this road, is to seperate out the various
> subsystems and give them each their own kernel task or workqueue.

Thaaaaaaat'd be so nice ... it'd also waste a lot of resources ...
maybe; I don't know if everybody at the lkml would swallow it.

That grossly reminds me of Timesys ... btw

> Then those who need to could adjust, for example, network code to run
> ..<snip>.. If you give any kernel thread an untouchable priority, you
> might just as well move the work back to a bottom half or even the
> interrupt code.

My fault in not being more precise: on setting kernel stuff to FIFO 99+1,
for example, I was talking about defaults; users (better, admins/
designers) should be able to then tweak it (specially on embedded systems).

My point is that when Joe Sixpack fires some common appl that happens
to use RT things, he doesn't have to understand the whole book on
realtime and stuff to be able to tweak the system so it works.

In fact, Robert's point is the best, IMHO. Basically you add some more
priority space (20, I think he mentions) that are reserved for
system stuff (I think Solaris has something similar). They are the
only ones that can use that priority space, asides from the normal
space reserved to the user.

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/



This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:28 EST