On Mon, 24 Apr 2000, Mark Hahn wrote:
> > > blockage within the IDE code when using UDMA with DMA is 90 microseconds
> > > (500MHz CPU). When interrupts are unmasked this comes down to 32 usecs
> ...
> >> that meanx if you can save 60usecs on each run, you will gain about
> > 12% in terms of CPU performance.
>
> which you DON'T. the numbers quoted were max latency; the average numbers
> were different by only a handful of us (17.1 vs 7.6 us). in fact, I
> speculate that most of the masking in this driver is superfluous
> (ie, one PIIIX at least, each channel normally has its own IRQ, and
> Linux single-threads IRQ-handlers, and ATA can only ever talk to one
> disk at a time. so why should interrupts EVER be masked in DMA/UDMA?)
argh, you are partially right , you gain not that, much, but sometime for
realtime apps, we have to take the worst case into account,
that means if we utilize the full CPU and the 90usec case happens,
we will miss our timeframe. For RT apps, what counts is worst case.
Therefore it's a good practice to try to keep it down (if it's not too
expensive)
>
> > My example was a program which does heavy computations (using up to 80% of the
> > CPU) between each 500usec run.
> > That means without unmasking you might loose 10-15% in terms of CPU
> > performance.
>
> wait a minute! irq masking only delays other irq's. we're not talking
> about something that eats CPU, like PIO. (actually, ide_wait_stat is a
> pretty revolting function that _does_ eat CPU, and afaikt, unnecessarily.)
Take my MIDI example:
midi thread:
while(1) {
read() from /dev/rtc which wakes us up each 500usec
do cpu intensive stuff
write() to MIDI device (not always, but when MIDI events need to get out)
}
I know we aren't speaking of PIO, but the delay of other IRQ's will
let the read() from /dev/rtc return up to 90usec later , which hurts compared
to the 500usec timeframe.
Since we have still to meet the deadline, we have 10-15% less time to spend in
the cpu intensive part of the loop.
Therefore IRQ masking "EATS" CPU.
(that means it delays your thread, I am not speaking about the CPU being idel
during this time and trying to execute another task while waiting these
90usec, that's just useless since the timeframe is so short)
>
> > Not taking advantage of the unmask IRQ feature, is the same as preferring
> > a big spinlock instead of multiple finegrained ones.
>
> no, it's quite different. irq-masking should only be to protect some
> old/bogus systems when in PIO mode. it's a work-around for a hardware bug,
> not part of (a decent) locking design.
I agree, but I want full performance from my MODERN hardware,
and a way to do this is to use unmask IRQ, even if for most of people this means
nothing.
But when you try to push your system to the limits, the bottlenecks will quickly
show up. (even if I wouldn't call the IRQ masking a serious one)
>
> regards, mark hahn.
Benno.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:07 EST