[lkml]   [2000]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: new IRQ scalability changes in 2.3.48
    Linus Torvalds wrote:
    > Note that these issues are completely off the map of what is really
    > meaningful at this point.
    > We want to avoid having long latencies, and we can easily get that by just
    > allowing timer interrupts to schedule which we're in a big
    > "memcpy_to_user()" and we don't hold any kernel lock etc. No need to try
    > to be clever at lock release time - if we get a pending reschedule, we
    > might as well leave it pending, it's going to be serviced soon enough
    > anyway.

    Ingo's bog standard low-latency patch is already said to do a fine job
    down to 0.5ms or so, and it does what you suggest.

    The problem remains with various bits of code that aren't audited for
    low latency (there will always be some). Drivers that spend ages in a
    loop (see recent fbcon thread for example). Random bits of
    uninteresting vfs or mm code that haven't been examined.

    These off-the-map issues are designed to address that stuff. To do what
    the low latency patch does, but guarantee it works everywhere. Assuming
    none of the unaudited code holds a spinlock for ages.

    So you can have a high priority thread that can process audio in real
    time (for example), or a softmodem user space driver (other completely
    random example). Note that RTLinux isn't really suitable for those --
    RTLinux isolates the real time process too much. And super-hard isn't
    required for those applications anyway.

    You suggestion of timer interrupts would actually be good enough for
    audio and softmodem apps, if you crank up the timer to 1kHz. So would
    the device interrupts probably.

    But the idea of only preempting during memcpy_to_user isn't enough --
    some code loops for ages and it's not doing memcpy_to_user.

    -- Jamie

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

     \ /
      Last update: 2005-03-22 13:57    [W:0.024 / U:9.476 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site