Messages in this thread | | | Date | Fri, 27 May 2005 18:07:23 +1000 | From | Nick Piggin <> | Subject | Re: 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/
| |