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

[Ingo Molnar]

* Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:

> ... and my point is that there is not much reason to introduce a 
> possible performance regression because of such a latency in an 
> artificial test case, especially when there are other sources of 
> unbound latency when dealing with large numbers of tasks (and on 
> uniprocessor too, eg. rwsem).
> 
> 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.

to answer your question: yes, all hardware interrupt handlers [except a 
very slim shim that blocks the irq source and wakes up the interrupt 
thread] are fully preemptible in the -rt kernel too. I.e. all the IDE 
irq handlers, all the networking handlers, all the irq codepath that 
usually runs with irqs off, runs fully preemptible in the -rt kernel.

so when we say the -rt kernel has a 20 usecs worst-case scheduling 
latency on a fast box, while running arbitrary SCHED_OTHER workloads 
(including heavy networking, heavy swapping/VM and IO work, using 
thousands of tasks) it really means we measured it using robust methods.

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

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/