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

Ingo Molnar
2004-08-02T07:38:41Z

* 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