[lkml]   [2005]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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

> 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

> 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

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

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-05-28 08:53    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean