[lkml]   [2006]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Avoid moving tasks when a schedule can be made.

    * Nick Piggin <> 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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-02-01 15:16    [W:0.024 / U:83.404 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site