Re: 2.2.2: 2 thumbs up from lm

Richard Gooch (rgooch@atnf.csiro.au)
Thu, 25 Feb 1999 22:01:01 +1100


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/