lkml.org 
[lkml]   [2001]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Preemption Latency Measurement Tool
    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.

    George

    >
    > > even i dont get any skips when i run the player at nice -n -20. That
    > > doesn't tell you much about the preemption patch though. And it doesn't tell
    > > you about performance when you dont give linux the chance to do what it does,
    > > multitask. That's where the latency patch is directed at improving, i
    > > think.
    >
    > Agreed.
    >
    > --
    > Robert M. Love
    > rml at ufl.edu
    > rml at tech9.net
    -
    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.031 / U:0.016 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site