lkml.org 
[lkml]   [2001]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Preemption Latency Measurement Tool
On Thu, 20 Sep 2001, Dieter Nützel wrote:

> Am Donnerstag, 20. September 2001 23:10 schrieb Robert Love:
> > On Thu, 2001-09-20 at 04:21, Andrea Arcangeli wrote:
> > > > You've forgotten a one liner.
> > > >
> > > > #include <linux/locks.h>
> > > > +#include <linux/compiler.h>
> > >
> > > woops, didn't trapped it because of gcc 3.0.2. thanks.
> > >
> > > > But this is not enough. Even with reniced artsd (-20).
> > > > Some shorter hiccups (0.5~1 sec).
> > >
> > > I'm not familiar with the output of the latency bench, but I actually
> > > read "4617" usec as the worst latency, that means 4msec, not 500/1000
> > > msec.
> >
> > Right, the patch is returning the length preemption was unavailable
> > (which is when a lock is held) in us. So it is indded 4ms.
> >
> > But, I think Dieter is saying he _sees_ 0.5~1s latencies (in the form of
> > audio skips). This is despite the 4ms locks being held.
>
> Yes, that's the case. During dbench 16,32,40,48, etc...

You might actually be waiting on disk I/O and not blocked.

Does your audio source depend on any files (eg mp3s) and if so, could they
be moved to a ramfs? Do the skips go away then?

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."

-
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 13:03    [W:0.193 / U:19.024 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site