* Nick Piggin <[email protected]> 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 [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]
