Because he is trying to change the kernel in a way that is obviously
application specific, doesn't help the general case, and wasn't been
shown to be necessary. It's not progress, it's just wacking the kernel
so it works for him. He has every right to do that, but he has no right
to expect that application specific hacks are going to show up in the
generic kernel.
: I don't care if it fixes his problem or not. If it looks sensible and
: actually speeds something up without slowing the common case down,
: it's a good idea to integrate it.
Thank God that this isn't how Linus works. No matter what you do to
the kernel, there are always side effects that you didn't think of,
no matter who you are. So when you are working in critical areas,
you want to have really thought things out before you put them in.
This is a critical area.
: One of the cornerstones of computer science is
:
: Make the common case fast.
:
: Your argumentation about long RT run queues is not a valid argument.
: The common case is clearly to have an empty RT run queue or one with one
: process (MP3 player) and people who want to do hard RT will want to use
: RTLinux, anyway.
That's amusing. I argued that short run queues are the common case so
that there is no problem. Other's argued that RT Linux is where Mr Gooch
should be and I supported that argument. Mr Gooch insisted that long
run queues are common. OK, if we want to accept that (which I don't),
then it follows that the problem will just migrate from the current run
queue to the RT run queue.
Furthermore, others have argued that long RT run queues will become
common as more applications become interactive. This is an argument
that sounds somewhat plausible. It follows then that whatever fix is
applied, it should accomidate this sort of workload. Mr Gooch's fix
does not do that, it just rearranges things so that they happen to work
with his particular workload. That's not progress for anyone except him.
I'm strongly against solutions that aren't well thought out and general
purpose. So if someone is going to rework the scheduler for RT processes,
they'd have to make it better than it is now. Just creating two queues
doesn't come close to doing that, it just happens to work for Mr Gooch.
The real answer for Mr Gooch is to use RT Linux or a special driver.
If he has a model where one process needs to do a tiny amount of work and
pass on the results, then that is perfect for either RT Linux or for a
hacked version of the driver. Think about it this way: the cost of a
context switch is non zero no matter what you do. If you aren't going
to use that context for anything other than passing an int around, then
it would be far more effective to just do it all without ever involving
a process context.
I feel that building a system which encourages bad design is just not
a good way to go. I also feel that Mr Gooch's application is poorly
designed. It's fine that they don't want to change that, but it's not
fine that they want to change the kernel to match their application.
If someone wants to rewrite the RT support, that's great. But that
rewrite needs to be generic enough that it won't just need to be rewritten
again for the next (different) application.
The approach of "well, it looks good, let's integrate it" is what kills
operating systems. To the extent that you care about Linux, you should
fight that with all of your ability. Remember to step back and consider
what would happen to the system if everything was changed just a little
for some application. Yup, each change, /!/taken in isolation/!/ looks
harmless or at least pretty good. But add 'em all up. Starts to look
gross.
-
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/