Subject: Re: [linux-audio-dev] interesting 2.3.4* kernel statistic
From: Benno Senoner (sbenno_AT_gardena.net)
Date: ti helmi 22 2000 - 10:14:37 EST
On Tue, 22 Feb 2000, David Olofson wrote:
> On Sun, 20 Feb 2000, Paul Barton-Davis wrote:
> > Someone on linux-kernel ran SGI's lockmeter, and notes:
> >
> > P.S.: some good news: except do_close
> ^^^^^^^^
> When does this happen?
>
> > [up to 34 milliseconds], noone
> ^^^^
> *aaaargh!* Can'n happen that often, right?
> (OTOH, this might be good news for *us*...! >:-D )
>
> > else owns a spinlock for more than 3 milliseconds.
> ^^^
> Seems like a very long time
> for a lock in a kernel that's supposed to do real time...
>
> > I don't know if this is "good" news, but there we have it.
>
> Well, to me it seem like another "Oh, I thought we had some
> competition *there*, at least..." Perhaps we do, but these figures
> aren't as impressive as one would expect from a *preemptive* kernel.
> After all, making a kernel preemptive (viewed per CPU, that is), is
> to great extent a performance hack for this kind of things... As we
> can see on Linux + the lowlatency patches, it's not really needed! :-)
>
>
> //David
I am a little confused by the numbers:
With the lowlatency patches we achieve <2-3ms latencies ALWAYS,
even when closing files etc.
Latencytest ran on my P133 while accessing the disk heavily , stress proc ,
and copying the entrire content of two CDs from TWO CDROM drives
simultaneously, and a close() call is issued zillions of time during my tests.
Therefore I don't understand how/if the lockmetering can be applied to do any
inferency on how small latencies we can get out of our realtime apps.
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST