lkml.org 
[lkml]   [2005]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RT patch acceptance
Ingo Molnar wrote:

Thanks Ingo,

> * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
>
>>Presumably your RT tasks are going to want to do some kind of *real*
>>work somewhere along the line - so how is that work provided
>>guarantees?
>
>
> there are several layers to this. The primary guarantee we can offer is
> to execute userspace code within N usecs. Most code that needs hard
> guarantees is quite simple and uses orthogonal mechanisms.
>

Well yes, but *somewhere* along the line they'll need to interact
with something else in a timely (in the RT sense) manner?

[...]

>
>>So in that sense, if you do hard RT in the Linux kernel, it surely is
>>always going to be some subset of operations, dependant on exact
>>locking implementation, other tasks running and resource usage, right?
>
>
> yes. The goal is that latencies will fundamentally depend on what
> facilities (and sharing) the RT task makes use of - instead of depending
> on what _other_ tasks do in the system.
>

OK.

>
>>Tasklist lock might be a good example off the top of my head - so you
>>may be able to send a signal to another process with deterministic
>>latency, however that latency might look something like: x + nrproc*y
>
>
> yes, signals are not O(1).
>
> Fundamentally, the Linux kernel constantly moves towards separation of
> unrelated functionality, for scalability reasons. So the moment there's
> some unexpected sharing, we try to get to rid of it not primarily due to
> latencies, but due to performance. (and vice versa - one reason why it's
> not hard to get latency patches into the kernel) E.g. the tasklist lock
> might be convered to RCU one day. The idea is that a 'perfectly
> scalable' Linux kernel also has perfect latencies - the two goals meet.
>

I'd have to think about that one ;)
But yeah I agree they seem to broadly move in the same direction,
but let's not split hairs.

>
>>It appears to me (uneducated bystander, remember) that a nanokernel
>>running a small hard-rt kernel and Linux together might be "better"
>>for people that want real realtime.
>
>
> If your application model can tolerate a total separation of OSs then
> that's sure a viable way. If you want to do everything under one
> instance of Linux, and want to separate out some well-controlled RT
> functionality, then PREEMPT_RT is good for you.
>
> Note that if you can tolerate separation of OSs (i.e. no sharing or
> well-controlled sharing) then you can do that under PREEMPT_RT too, here
> and today: e.g. run all the non-RT tasks in an UML or QEMU instance.
> (separation of UML needs more work but it's fundamentally ok.) Or you
> can use PREEMPT_RT as the nanokernel [although this sure is overkill]
> and put all the RT functionality into a virtual machine. So instead of a
> hard choice forced upon you, virtualization becomes an option. Soft-RT
> applications can morph towards hard-RT conditions and vice versa.
>

OK. I what sort of applications can't tolerate the nanokernel type
separation? I guess the hosts would be seperated by some network like
device, shared memory, etc. devices that use functionality provided
by the nanokernel?

> So whether it's good enough will have to be seen - maybe nanokernels
> will win in the end. As long as PREEMPT_RT does not impose any undue
> design burden on the stock kernel (and i believe it does not) it's a
> win-win situation: latency improvements will drive scalability,
> scalability improvements will drive latencies, and the code can be
> easily removed if it becomes unused.

Well yeah, from what I gather, the PREEMPT_RT work needn't be excluded
on the basis that it can't provide hard-RT - for a real world example
all the sound guys seem to love it ;) so it obviously is worth something.

And if the complexity can be nicely hidden away and configured out,
then I personally don't have any problem with it whatsoever :) But
I don't like to comment further on actual code until I see the actual
proposed patch when you're happy with it.

Nick
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-27 10:12    [W:2.270 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site