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

[Ingo Molnar]

* Lee Revell <rlrevell@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/