Re: RT patch acceptance

[Nick Piggin]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/