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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ingo Molnar wrote:
* Nick Piggin <[email protected]> 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 -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux