lkml.org 
[lkml]   [2005]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RT patch acceptance
    Bill Huey (hui) wrote:
    > On Sat, May 28, 2005 at 01:53:59PM +1000, Nick Piggin wrote:
    >
    >
    > OpenGL must be RT aware for the off screen buffer to be flipped. This
    > model isn't practical. With locking changes in X using something like
    > xcb in xlib, you might be able to achieve these goals. SGI IRIX is
    > enable to do things like this.
    >

    OpenGL seems to work just fine here, and it can flip off screen buffers.

    > Please try to understand the app issues here, because you seem to have
    > a naive understanding of this. [evil jab :)]
    >

    It's not an evil jab, because I do have a naive understanding of this.
    But nobody has been able to say why a single kernel is better than a
    nanokernel.

    > True, but XFS was designed to deal with this in the first place. It's
    > not that remote a thing and if you have a nice SMP friendly system so
    > it's possible to restore that IRIX functionality in Linux.
    >

    Then it is also possible to have that functionality in a hard-RT
    guest kernel too.

    >
    > There's a lot of unknowns here, but XFS is under utilized in Linux.
    > I can't really imagine how a RT host kernel could really respect
    > something as complicated as XFS with all of it's tree balancing stuff
    > and low level IO submissions with concurrent reads/writes. The nanokernel
    > adapation doesn't fly once you think about how complex that chain is.

    Err, that wouldn't go in the nanokernel. Do you understand what I'm
    talking about? The nanokernel supervises a Linux guest and a hard-RT
    guest.

    > The RT patch is priming that path to happen already and I would like to
    > see this used more.
    >

    Sorry, you aren't going to make XFS in Linux generally realtime capable
    any time soon, so there is no point saying how hard it is going to be
    with a nanokernel.

    Oh hang on, wait a second here. *I* am not talking about removing
    atomic critical sections or interrupts off periods from the kernel
    so that your unrelated high priority userspace code or interrupt
    handler can run. I understand PREEMPT_RT has basically solved that.

    What I am talking about is an RT app calling into the kernel, and
    being granted some resource or service within a deterministic time.
    If you RT guys don't need such a thing, then let's clear that up
    now so we can all go home to our families ;)

    >
    > The problem with that assertion is that it's pretty close to being
    > hard RT as is. It's not that "mysterious" and the results are very
    > solid. Try not to think about this in a piecewise manner, but how
    > an overall picture of things get used and what needs to happen to
    > get there as well as all of the work done so far.
    >

    For interrupts that do nothing, and userspace code, I'm sure it
    is pretty close to being hard-RT. What I am talking about (what
    my original question asked), is what kind of useful RT work will
    people want to be using the kernel for, and why isn't a microkernel
    a better approach.

    Seems like a pretty simple question if (as everyone seems to be
    saying) the single kernel scheme is so obviously superior. No need
    for any handwaving about XFS, or X11, etc.

    >
    > They don't understand the patch nor the problem space, so I ignore
    > them since they'll never push any edge that interesting. And Ingo's
    > comment about the RT patch riding on SMP locking as is should not
    > be something that's forgotten.
    >

    Well it seems like maybe you don't have a good understanding of their
    problem spaces either. And if you ignore them, then that's fine but
    you won't get anything merged. (Ingo might, however ;) )

    >>Well, you would do the RT work in the RT kernel, then communicate
    >>the results to the Linux kernel.
    >
    >
    > Write a mini-app and see how this methodology is going to work in
    > this system. Both Ingo and me have already pointed out that folks
    > already doing general purpose apps need a simple model to work with
    > since they need to cross many kernel systems as well as app layers.
    >

    Yeah, Linux "does" general purpose apps fine today.

    > Stop thinking in terms of a kernel programmer stuck in 1995, but
    > something a bit more "large picture" in nature.
    >

    I would love to. I'm waiting for somebody to paint me a large picture.

    >
    >>you talk about doing _real_ work, that will require an order of
    >>magnitude more changes than the PREEMPT_RT patch to make Linux
    >>hard-RT. And everyone will need to know about it, from device
    >>driver writers and CPU arch code up.
    >
    >
    > Uh, not really. Have you looked at the patch or are you inserting
    > hysteria in the discussion again ? :) Sounds like hysteria.
    >

    OK, I'll start small. What have you done with the tasklist lock?
    How did you make signal delivery time deterministic?

    How about fork/clone? Or don't those need to be realtime? What
    exactly _do_ you need to be realtime? I'm not asking rhetorical
    questions here.

    >
    > Pretty much any call other an things related to futex handling. That
    > doesn't invalidate my point since I wasn't making a broad claim in
    > first place.
    >

    No, but my broad question was basically - how far will people want
    to go with this? And how is one method better than another?

    I understand there are some operations where PREEMPT_RT probably is
    very close to hard-RT. I have understood that from the start.


    >
    >>Suppose the PREEMPT_RT patch gets merged tomorrow. OK, now what
    >>if *you* needed a realtime TCP/IP socket. Where will you begin?
    >
    >
    > Start with the DragonFly BSD sources and talk to Jeffery Hsu about
    > his alt-q implementation. Their stack was parallelize recently and
    > can express this kind stuff with possible a special scheduler in
    > their preexisting token locking scheme. I'm not talking hard RT
    > here for RT enabled IO. Obvious this is going to be problematic
    > to a certain degree in a kernel and will have to be move more into
    > the realm of soft RT with high performance.
    >

    So why did you bring it up as a problem for the nanokernel approach
    if you can't handle it with the single kernel approach?

    My question is very simple. Just a simple "people need to do X, a
    nanokernel can't do X because ... a single kernel can do X" will be
    fine.

    And you needn't use vague examples with X11 or OpenGL. A concrete
    example, say a sequence of system calls would be fine.

    I really won't take much convincing, I just want some basic
    background.

    >
    >>Sorry, not much better... But don't waste too much time on me, and
    >>thanks, I appreciate the time you've given me so far.
    >
    >
    > Read the patch and follow the development. That's all I can say.
    >

    When you're ready to submit something to be included in the Linux
    kernel, then I'm sure you will have had time to write up a clea
    rationale and be able to address my questions on the linux kernel
    mailing list. I look forward to it ;)

    >
    >>I wouldn't consider a non response (or a late response) to mean that
    >>a point has been conceeded, or that I've won any kind of argument :-)
    >
    >
    > Well, you're wrong. :)
    >

    Wrong about what? While no doubt I've made one or two, I have tried
    to steer clear of making assertions.
    Send instant messages to your online friends http://au.messenger.yahoo.com

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-05-28 08:53    [W:0.034 / U:0.516 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site