Messages in this thread | | | Date | Thu, 25 Feb 1999 22:01:01 +1100 | From | Richard Gooch <> | Subject | Re: 2.2.2: 2 thumbs up from lm |
| |
Larry McVoy writes: > : > what misfeatures (if any) does it fix? > : > : Well, I wouldn't go so far as to say it fixes misfeatures. It's more > : about optimsations. It basically a result of the RT queue work I did, > : which showed that performance is being hampered by cache line > : aliasing. > > I hate to reopen this thread, but can you please produce someone > other than yourself or one of your pseudo-RT friends, who believe > that they have the problem that you are fixing. Actually, I don't > care if you produce said person, I'd just like that person to step > forward and say "yes, the scheduler is a problem for me and here is > why".
Indeed we've gone over this before. Anyway. I got interested in this stuff in response to questions and concerns from local people who write real-time software. I didn't start because I woke up one day and thought myself "hey, let's hack the scheduler today". It was a distraction I didn't need. But they asked and I gave them a hand.
Some of their software is hard RT, some is soft. Naturally, "soft" is a rubbery term. These people are considering moving to Linux for new developments and perhaps in the longer term for porting old codes.
Their current codebase is pSOS, and they are considering Victor's RT-Linux stuff as an alternative for the hard-RT applications. For the soft-RT applications, they are considering using "normal" Linux using the POSIX RT extensions, because it provides a richer and easier programming environment.
Right now, they don't have any RT code running under Linux, so in a sense, it's all vapourware (or perhaps you'd say "vapourproblems"). However, consideration of the applications points to potential problems with the current scheduler behaviour, as I've outlined before. For that group, there is an understandable reluctance to jump all the way into Linux given the potential problems.
I'm not saying the current scheduler will absolutely *be* a problem. We can't know that until an application is ported or written and tested. But we see a potential problem, and that increases the barrier to switching to Linux. So we have a chicken-and-egg problem.
There is another group doing RT coding for Digital Unix. I'd like to urge them to use Linux instead, but there are certain political problems there, and the time isn't right for pushing with them. For that group, a push to Linux would be easier to start if the first group had some runs on the board (i.e. a few RT applications running under Linux).
So, other that these two groups, I don't have "examples" to throw at you. I also think it's a bit unfair to label people who agree with me as "pseudo-RT friends". Does that mean I've seduced them into towing the RGooch party line? Perhaps they've just camly evaluated the arguments on both sides and decided I'm right.
Applying that label seems like a pre-emptive strike to discredit anyone who agrees with me. By what yardstick do you measure whether a person has been seduced by my infinite charms (yeah, right:-) or if they've used their neocortex as per specification?
> If you want to hack the scheduler for your own needs, that's great, > have the big fun. But if you want to tinker with that part of the > system which effects every single user, then it would not seem > reasonable for you to provide some examples of people who want this > fixed? Fair enough?
Ignoring the fact that my changes had a net benefit for the general case, what you ask is difficult for the reasons I've outlined above.
The best I can do in response is ask that someone out there with a soft-RT Linux application steps forward if they're having timing problems and we can see if it's due to the scheduler.
Regards,
Richard....
- 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/
| |