lkml.org 
[lkml]   [1999]   [Feb]   [26]   [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:
    > : Yes, but I've been doing most of my benchmarks on a PPro and plain
    > : P5's. And some of the target machines they have in mind are lowly
    > : 386's or 486's. 386 embedded systems are expensive enough, going to
    > : 486 or beyond adds a lot to the cost.
    >
    > Anyone who is telling you this needs to do their homework. Go look
    > at StrongARM and get NDAed. They will offer your pricing which is
    > more attractive and offer you a part that has far lower power and
    > power/MIPS costs. I know what I'm talking about, go check it out,
    > you'll be glad you did. If you don't get the info you need, contact
    > me privately and I'll put you in touch with the right people.

    Alan pointed out problems with that. Also, consider that there is an
    installed base of hardware which isn't going to be replaced anytime
    soon. At least not here. The way this place works is that funding for
    purchasses and funding for personnel is quite separate, so funding the
    effort to fit an application into available hardware is easier than
    buying the hardware to fit the application.

    I've hit my head against this brick wall more times than I care to
    think about. It's fustrating, but it's life.

    > : I don't claim to have all the answers. I have a number of ideas that
    > : I'd like to test. The main claim I make is that I don't think it's
    > : obvious which approach will be the best. At least I'm willing to code
    > : something and test it. That seems more constructive than persistently
    > : poo-pooing ideas
    >
    > Richard, it isn't the ideas that are the problem, it's the premise
    > behind them. I want you to get a solution that makes you happy, I
    > just don't want it at the expense of the generic kernel. A few
    > points to consider:

    Why do you keep saying that it's at the expense of the generic kernel?
    I've explained time and time again how the current code (all that
    special-casing for the RT scheduling class) is complex and fragile,
    but you never respond directly to these points.

    My changes are cost neutral at worst and improve the quality of the
    scheduler code.

    > 1) We don't know if there is a problem. You yourself have said that
    > you just think there might be a problem and you want to "fix" it.
    > That's cool, but given that you haven't defined what you are
    > "fixing", it's sort of hard to justify the changes. Removing
    > cache misses in a benchmark test case is a poor justification.

    I've raised a number of points. It's all there in the document I wrote
    last year: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
    and the mail archives.

    > 2) The whole soft-RT stuff. I'd be a lot more supportive of your
    > efforts if it sounded like you understood the tension between
    > time sharing and RT. Can you explain why RT is not typically
    > found in time sharing OS's, the goals of each design, why they
    > conflict, etc. If you understood all that (maybe you do, but it
    > sure doesn't sound like it from your postings) and /then/
    > proposed your changes and explained how they actually made sense
    > in spite of the time sharing/RT problem, that would be far more
    > warmly received. At least by me.

    Well, I do understand the issues, but I'm not going to waste my time
    sitting your exam. If you look through the mail archives you can even
    see where I've talked about the advantage of RT and non-RT scheduling
    classes in a *single* application which is the only thing running on
    the system. The clock application I mentioned is one example of it.

    So don't present this as though I'm trying to push for RT applications
    running perfectly on a time-sharing system. Even where I *have*
    pointed out the benefits to a separate RT run queue for systems
    sharing RT applications and normal user processes, I've taken pains to
    mention that there are many other problems which have a greater effect
    on latency.

    When I say "this would help shared RT/normal systems", you should not
    take that to mean "this will solve problems sharing RT and normal
    jobs", nor even "this will solve the biggest problem...". I've even
    said in the past that, in the context of sharing RT and normal jobs, a
    separate RT run queue is one of the smaller issues.

    But there are other issues, which is why I think it's worth
    considering. Even the simple fact that it simplifies the scheduler
    code and makes it less fragile is in my view sufficient justification,
    even if there were no performance benefits at all.

    > 3) Linux/RT. I really wish that you would get your friends to use
    > this. If you need help with this, I'll beat on Viktor to help
    > you. Did you know there is a company which produes a Linux/RT
    > CD? Have you tried it? Have you worked as hard at solving your

    Getting hold of RT-Linux is not a problem. They don't need a CD.

    > problems in that space as you have worked on other approaches?
    > If not, why not? Is Viktor being unresponsive? We'll fix that.
    > Is there some feature that you need in the RT kernel that isn't
    > there? Spec it, I'll find someone to do it. It would be so nice
    > if you looked at this solution space in depth. It's a really
    > elegant solution and keeps the RT stuff, that 99.99% of the users
    > will never use, out of the kernel. I'd really like you to
    > balance your proposed changes with the need - that's a tradition
    > in Linux, and it is a good one. The road of operating systems is
    > littered with carcasses of examples where people forgot that
    > balance and ended up with and OS that suited noone.

    I have no problem with the RT-Linux concept. I've said before I think
    it's a fine idea. The reaction I've received from people is that it's
    an incomplete programming environment (i.e. lack of semaphores). I've
    actually argued against them on some of these issues, pointing out
    that they could just use the RT pipes as a synchronisation
    method. Remember I'm talking to people who aren't used to the Unix
    way, so I've had to explain the Unix philosophy. It's hard work
    convincing someone that a "missing feature" doesn't mean an OS is
    lacking but rather that they've got the wrong mindset.

    Where I do agree with the criticisms is that using RT-Linux is hard,
    because it doesn't fit seamlessly into the Linux/Unix programming
    environment. You can't take standard POSIX RT code and have the POSIX
    RT threads be RT-Linux threads. You have to stuff around with loading
    modules and separating your code into co-routines: separate
    programmes. I'd like to see this changed.

    Ideally, a thread could ask to become an RT-Linux thread (using
    sched_setscheduler()). I acknowledge this is hard to achieve, but it's
    what would make using RT-Linux so much easier. This is important for
    people who have a certain reluctance in the first place. [*]

    > I'm serious about being willing to help you if you are willing to
    > explore other alternatives. I agree that the RT kernel that Viktor
    > has isn't as rich a programming environment as the generic kernel.
    > So lets fix that. Lets understand what it would take to solve your
    > problem and beat on the Linux/RT folks to be responsive to your
    > needs. If we can't get them to help you, then you have a really
    > strong case for fixing your stuff in the generic kernel. But please
    > give them a chance first.

    Well, I've given some of my suggestions. Lets take that further. The
    changes I proposed to the standard Linux scheduler do 2 things:

    - improve RT performance by isolating the run queues

    - improve robustness and maintainability of the code by
    simplification.

    If we ignore the first issue and just look at the second, let me
    propose a perhaps radical idea: we *remove* SCHED_FIFO and SCHED_RR
    from the standard Linux scheduler. This would also simplify the
    scheduler, making it faster and more robust. All that special-casing
    for POSIX RT would be removed.

    Of course, we have to support the POSIX RT scheduling classes, so just
    removing them isn't really an option. But suppose instead my (perhaps
    unrealistic) idea mentioned above (*) was implemented so that a thread
    which asked for RT scheduling got *real* RT? Now that would be nice.

    Before you flame me, I'll say that I haven't thought out the problems
    with implementing this. Take it is as a "wouldn't it be neat if...".

    Assuming the above idea is dumb, please address the issue of the
    current complexity and fragility of the standard scheduler. If there's
    to be any hope of a productive debate, this issue needs to be
    addressed.

    I would be apprehensive in pushing a patch that added a separate RT
    run queue *if it added complexity to the current code*, for the very
    same reasons you have. I agree with the principle of reducing kernel
    bloat (although it shouldn't be a straight-jacket). But my patch
    *simplifies* the scheduler. This is why Linus was positive about it in
    the first place, I believe. The patch just makes things so much
    cleaner.

    If you prefer the current complexity, at least explain *why*.

    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:3.290 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site