Re: RT patch acceptance

["K.R. Foley" <kr@cybsft.com>]

Nick Piggin wrote:
> 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.

I think this is an excellent point and one that is often missed by the 
opponents of lower latencies in favor of throughput. At the risk of 
over-simplification: If your task takes 20ms vs. 10ms eventually those 
extra 10ms, every time your task runs, add up to real, noticeable wall 
clock time. Unless you live in a world where you have unlimited CPU 
resources, lower latencies (or maybe more correctly determinism) have to 
be beneficial to throughput also. In a case where it cost throughput 
because of the context changes created by higher priorty tasks 
preempting lower priority tasks, change the priorities so that the tasks 
don't get preempted. I believe that in a case where all codepaths have 
been made to be as efficient and deterministic as possible, you remove 
most of the unknowns that the OS can throw at you. Doesn't this leave it 
to the application designer/developer to make his app perform at the 
best possible level?

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

I am not saying this is the case with all of these environments, so 
please noone start throwing things at me. Imagine if you will a world 
where there is no shared memory between RT tasks and non RT tasks. 
Imagine a world where such tasks must share data via a pipe. Imagine if 
you will a world where you don't just have to make your application as 
fast and efficient as possible but you also have to build your own 
facilities (such as IPC) that you take for granted in normal Linux 
environment. To my knowledge there are very few RT environments today 
where you don't have to live with these types of constraints. The ones 
that I know about where you don't are not nanokernel type environments.

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


-- 
    kr