lkml.org 
[lkml]   [2004]   [Aug]   [2]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateMon, 2 Aug 2004 09:39:38 +0200
FromIngo Molnar <>
SubjectRe: [patch] voluntary-preempt-2.6.8-rc2-M5
* 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