Messages in this thread | | | Subject | Re: [patch] voluntary-preempt-2.6.8-rc2-M5 | From | Lee Revell <> | Date | Sun, 01 Aug 2004 20:46:26 -0400 |
| |
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/
| |