lkml.org 
[lkml]   [1999]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.2.2: 2 thumbs up from lm
Larry McVoy writes:
> : 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.
>
> Great. Then solve the problem after you _know_ there is a problem.
> Several people have told you that they don't like your approach. That
> should be enough for you to have to justify your changes with real
> applications which have been proven to be hitting this problem. That
> should be trivial, according to you, because you have repeatedly come
> up with long arguments as to why it must be true. Fine. Show that it
> is true before you tinker with the scheduler. It's too important
> to be changed because you think there might be a problem. Don't you
> agree?

I'd agree *if* my changes hurt performance. I've already demonstrated
that even the general case sees a net improvement.

> : I also think it's a bit unfair to label people who agree with me
> : as "pseudo-RT friends".
>
> Come on Richard, you're just being defensive. You seem to represent
> a set of people who don't want RT but they want some other thing
> which you call "soft-RT".

They want POSIX RT == soft-RT. Is that specific enough? Is it such a
strange concept to want to use POSIX RT?

> I, and others with more experience in this area, question the
> validity of any sort of real time features in a multi user, time
> sharing system. We happen to believe that the two disciplines are
> mutually exclusive.

I don't agree. I think there is some overlap. I don't think it's as
black-and-white as you make out.

> I don't know what you want me to call your friends, but they seem to
> like this strange thing you call "soft-RT". Since that is not
> considered real time by _any_ textbook or _any_ credible published
> paper, I'm feel completely justified in calling it "pseudo-RT". So
> you have these friends, they like your ideas, your ideas are
> focussed on pseudo-RT, so I called them your pseudo-RT friends.
> What's the problem?

Perhaps I misinterpreted you. I felt that you were labelling and
dismissing those (not just local colleagues) who supported my ideas.

> : > 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.

You never seem to address this point. If you don't like the idea of
better RT in the kernel, then look at it this way: my changes provided
a net improvement for non-RT processes. Think of it as just another
optimisation. A bit of cycle shaving.

I'll mention that you also have ignored other points I've brought up,
such as the current scheduler being complicated, messy and fragile. If
a change is cost-neutral at worst, and tidies up the code, then why
object so strenuously?

> : 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.
>
> Great, that's a perfectly reasonable thing to do. I'd like to
> exclude from that set of people your friends, because you are
> clearly the technical lead for your friends so their independence is
> clearly in question.

Cough! You wouldn't say that if you knew the politics involved.

> I'd like to know if there is someone else who can demonstrate a need
> for the changes you want to make to the scheduler. If nothing else,
> maybe I'll learn something.

Time will tell. In any case, since we don't seem to be convincing each
other, why not agree to disagree? You don't bother addressing other
points I raise for some reason, so the debate seems a bit pointless.

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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.157 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site