Messages in this thread |  | | From | Dieter Nützel <> | Subject | Re: [PATCH] Preemption Latency Measurement Tool | Date | Sun, 23 Sep 2001 06:06:49 +0200 |
| |
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[unhandled content-type:application/x-bzip2] |  |