Re: [PATCH] Preemption Latency Measurement Tool

["Dieter Nützel" <Dieter.Nuetzel@hamburg.de>]

[-- Attachment #1: Type: text/plain, Size: 2530 bytes --]

Am Sonntag, 23. September 2001 05:14 schrieb george anzinger:
> Robert Love wrote:
> > On Sat, 2001-09-22 at 19:40, safemode wrote:
> > > ok. The preemption patch helps realtime applications in linux be a
> > > little more close to realtime.  I understand that.  But your mp3 player
> > > shouldn't need root permission or renicing or realtime priority flags
> > > to play mp3s.
> >
> > It doesn't, it needs them to play with a dbench 32 running in the
> > background.  This isn't nessecarily acceptable, either, but it is a
> > difference.
> >
> > Note one thing the preemption patch does is really make `realtime' apps
> > accel.  Without it, regardless of the priority of the application, the
> > app can be starved due to something in kernel mode.  Now it can't, and
> > since said application is high priority, it will get the CPU when it
> > wants it.
> >
> > This is not to say the preemption patch is no good if you don't run
> > stuff at realtime --  I don't (who uses nice, anyhow? :>), and I notice
> > a difference.
> >
> > > To
> > > test how well the latency patches are working you should be running
> > > things all at the same priority.  The main issue people are having with
> > > skipping mp3s is not in the decoding of the mp3 or in the retrieving of
> > > the file, it's in the playing in the soundcard.  That's being affected
> > > by dbench flooding the system with irq requests.  I'm inclined to
> > > believe it's irq requests because the _only_ time i have problems with
> > > mp3s (and i dont change priority levels) is when A. i do a cdparanoia
> > > -Z -B "1-"    or dbench 32.   I bet if someone did these tests on scsi
> > > hardware with the latency patch, they'd find much better results than
> > > us users of ide devices.
> >
> > The skips are really big to be irq requests, although perhaps you are
> > right in that the handling of the irq (we disable preemption during
> > irq_off, of course, but also during bottom half execution) is the
> > problem.
> >
> > However, I am more inclined to believe it is something else.  All these
> > long held locks can indeed be the problem.
> >
> > I am on an all UW2 SCSI system, and I have no major blips playing during
> > a `dbench 16' (never ran 32).  However, many other users (Dieter, I
> > believe) are on a SCSI system too.
>
> Dieter, could you post your .config file?  It might have a clue or two.

Here it comes.

Good night ;-)

-Dieter

BTW I have very good results (not the hiccup) for 2.4.10-pre14 + ReiserFS 
journal.c-2-patch from Chris

[-- Attachment #2: config.bz2 --]
[-- Type: application/x-bzip2, Size: 4370 bytes --]