Re: [patch] voluntary-preempt-2.6.8-rc2-M5

[Lee Revell <rlrevell@joe-job.com>]

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