Paul Barton-Davis writes:
> The problem is that many people here, including Linus, and to some
> extent Ingo himself, don't like the solution that exists today. At
> the same time, various people have insisted "the only solution to
> this is hard real-time support" in more or less the same breath that
> they've said "hard real-time should never be part of the Linux
> kernel".
You missed out " and should be in RTLinux instead".
> So, what's the take home story from that pair of statements ? The
> most optimistic I can construct is "we'll accept some changes that
> reduce the real hogs down to a reasonable range by comparison with
> the rest of the system, but if thats not good enough, too bad. This
> ain't a niche OS like BeOS, you know."
There's also the open invitation to go code up a better patch.
In fact, probably the best option is to write (or sponsor) a patch to
RTLinux so that Linux user-space processes can be scheduled by the
RTLinux scheduler. If you submit such a patch to Victor Y., and it was
configurable (so that you don't always have to pay the extra penalty
for swapping VM contexts), I would expect he'd accept it.
It would keep him happy (hard-core RT users still get the best
latencies), it would keep you happy (you get good latencies 100% of
the time) and it would keep Larry happy ("git the hell otta that thar
kernhal"). And as a bargain extra, it would keep me happy (I could
send in a patch ripping out SCHED_FIFO and SCHED_OTHER and hence clean
up the Linux scheduler).
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:11 EST