Re: [PATCH] Avoid moving tasks when a schedule can be made.

[Nick Piggin <nickpiggin@yahoo.com.au>]

Ingo Molnar wrote:
> * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 

>>However, as an RT-tree thing obviously I have no problems with it, but 
>>unless your interrupt thread is preemptible, then there isn't much 
>>point because it can cause a similar latency (that your tools won't 
>>detect) simply by running multiple times.
> 
> 
> we can (and do) detect any type of latency. E.g. there's the 
> CONFIG_LPPTEST feature in the -rt kernel, which allows me to inject 
> 50,000 hardirqs per second from another box, over a parallel port, and 
> allows me to validate the worst-case IRQ response time from that 
> external box. The 'external' component of LPPTEST injects the interrupt 
> with interrupts disabled, and polls for the response, and does all 
> measurements on that other box. I can use that in conjunction with the 
> latency tracer running on the measured box, to get an easy snapshot of 
> the longest hardirq latency path.
> 

What I am talking about is when you want a task to have the highest
possible scheduling priority and you'd like to guarantee that it is
not interrupted for more than Xus, including scheduling latency.

Presumably this is your classic RT control type application.

Now in your kernel you can measure a single long interrupt time, but
if you "break" that latency by splitting it into two interrupts, the
end result will be the same if not worse due to decreased efficiency.

This is what I was talking about. But that's going off topic...

>>You really want isolcpus on SMP machines to really ensure load 
>>balancing doesn't harm RT behaviour, yeah?
> 
> 
> not really - isolcpus is useful for certain problems, but it is not 
> generic as it puts heavy constraints on usability and resource 
> utilization. We have really, really good latencies on SMP too in the -rt 
> kernel, with _arbitrary_ SCHED_OTHER workloads. Rwsems and rwlocks are 
> not an issue, pretty much the only issue is the scheduler's 
> load-balancing.
> 

Then it is a fine hack for the RT kernel (or at least an improved,
batched version of the patch). No arguments from me.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com