lkml.org 
[lkml]   [2004]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [patch] voluntary-preempt-2.6.8-rc2-M5
    From
    Date
    On Sun, 2004-08-01 at 19:37, Lee Revell wrote:
    > On Sun, 2004-08-01 at 07:28, Ingo Molnar wrote:
    > > could you try to repeat the '50 usecs' test with -L2 [that was the one you
    > > used?] to make sure it's repeatable?
    >
    > Results with L2, soundcard + RTC interrupts 'direct', N=1,000,000:
    >
    > Delay Count
    > ----- -----
    > 6 24330
    > 7 429668
    > 8 34474
    > 9 26184
    > 10 12210
    > 11 9060
    > 12 9104
    > 13 8460
    > 14 11011
    > 15 13615
    > 16 14584
    > 17 13371
    > 18 12169
    > 19 10864
    > 20 11936
    > 21 7974
    > 22 6256
    > 23 4888
    > 24 2385
    > 25 640
    > 26 164
    > 27 113
    > 28 86
    > 29 105
    > 30 90
    > 31 86
    > 32 103
    > 33 140
    > 34 149
    > 35 183
    > 36 160
    > 37 141
    > 38 147
    > 39 146
    > 40 172
    > 41 140
    > 42 131
    > 43 89
    > 44 54
    > 45 10
    > 46 3
    > 47 2
    > 49 3
    >

    The above histogram was generated with normal desktop activity going
    on. Another run under the same conditions produced the same three
    "humps". Here are the results with an idle system:

    Delay Count
    ----- -----
    6 8460
    7 481093
    8 66311
    9 43167
    10 23021
    11 5536
    12 3883
    13 3370
    14 3635
    15 3923
    16 3419
    17 2892
    18 2615
    19 2659
    20 5239
    21 3607
    22 1289
    23 662
    24 237
    25 59
    26 28
    27 15
    28 17
    29 24
    30 29
    31 50
    32 65
    33 34
    34 34
    35 23
    36 29
    37 19
    38 25
    39 36
    40 42
    41 22
    42 18
    43 8
    44 5

    The second hump centered at 20-21 usecs is still present, but smaller.
    The third hump centered at 31-32 is barely detectable, but present,
    repeating the test showed the same thing.

    So the first hump is the fast path, interrupt -> scheduler -> jackd with
    the fewest possible context switches, and a hot or warm cache. The
    third would have to be the worst case scenario (relatively speaking),
    where we preempt another process in one of the longer common critical
    sections.

    The second hump seems like either the same situation as the fast path,
    except with a cold cache, or where we have to preempt another process
    that is not in a critical section at all, or a short one.

    If we have any suspects for the code paths involved, couldn't this be
    verified by adding a udelay(10) to the path, and verifying that the hump
    moves by 10? This technique could also be used to distinguish different
    code paths with similar execution times. It looks like they are finite
    and few in number.

    At this point there are no latency problems I can see, all that remains
    is to understand the causes of the observed latencies. Then assuming
    any "direct-irq" drivers and anything you run SCHED_FIFO is realtime
    safe, what else remains to be done in order to make hard realtime
    guarantees?

    Lee

    Lee

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

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