![]() | |||||||||||||
Messages in this thread |
* Lee Revell <rlrevell@joe-job.com> wrote: > 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. i believe wli's latency-timing patch gives a pretty good indication of the code path(s) involved - i'm using something quite similar to that. The printout triggers immediately at the end of a high latency, so the stack contains a number of clues about what went on before. > 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? what remains i believe is to improve wli's patch and to observe (and fix) the maximum latencies. Also, your workload is a subset of what other people might be running so wider testing is obviously needed as well. btw., with what max_sectors setting were you testing during these tests? In -O2 the hardirqs are not preemptable (yet) so with 1024 sectors you should see quite high latencies due to the completion activity. Ingo - 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 [from the cache] ©2003-2008 | |||||||||||||