lkml.org 
[lkml]   [2000]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: new IRQ scalability changes in 2.3.48


    On Mon, 13 Mar 2000, Jamie Lokier wrote:
    >
    > You have to do them together. Just resched on irq won't give low
    > latency when you get an irq in a spinlock region.

    "perfect is the enemy of good".

    This adds complexity and makes the normal case slower.

    I'm already concerned about doing a single (nonatomic and completely
    parallell as far as the CPU is concerned) inc/dec for each spinlock
    operation. Adding conditional jumps to the mix makes it worse.

    > Note: In many cases, spinlock_irqsave doesn't need to do the
    > spinlock_depth thing on UP. However, not all cases: the code in the
    > lock region might wake up another task.

    The synchronous wake-up is an example of why we do NOT want to do your and
    Ingo's "perfect" case. It becomes nasty as hell.

    In contrast, the simple inc/dec without being clever and looking for
    pending schedules gets the above case right too. Not by magic, but just by
    being simple. We'll re-schedule at the proper time later on, which is what
    we want to do anyway.

    Sure, once in a blue moon we might be unlucky, and have a pending
    reschedule for longer than we want. Big deal, especially as we've never
    claimed to be hard-RT anyway.

    Linus


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

    \
     
     \ /
      Last update: 2005-03-22 13:57    [W:4.543 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site