On Wed, 20 Nov 2002, Michael R. Zucca wrote:

> Well, there are a few points:
> 1. Make this an option so that machines like the Quadras where we can 
> put the clock interrupt at a better level aren't forced to take the I/O 
> performance hit for this fix.

Certainly.  IMHO, though, the first rev should be an ifdef, moving to a
switchable flag if it turns out the performance difference is worth the
effort.  There's no guarantee that performance will actually
suffer.  It's really not changing the performance, but rather the
balancing point between compute and I/O bound process priority.  But I
digress.


> 2. If there are machines which use the esp SCSI driver but don't allow 
> us to change interrupt levels, then I'm not entirely sure this will 
> work.

I hope that's not the case.


> The reason is the pdma code must run with interrupts disabled. It 
> basically reads from a hunk of RAM over and over expecting the 
> occasional bus error to be issued when the pdma fifo over/underflows. If 
> this were handled in a thread that could be interrupted, then a random 
> interrupt handler might get the bus error. Basically, the hardware 
> requires some seriously hacky code to be fast. Unfortunately, it is the 
> disk code that causes the most problems with drift, so I'm not sure what 
> you can do in this case.

Ewww.  Ewww.  Ewww.  Ewww.  Ewww.  On UNDERflow?

The bus flow on overflow should be safe, since it can only occur when the
driver is actually pushing data into that chunk of RAM, right?  The
underflow case, assuming it can be detected easily, could be added to the
lowmem vector code for bus error handling with minimal penalty.  Since it
would presumably be safe to continue writing data to the buffer after an
underflow, the vector code could just set a flag in memory which could be
tested at the bottom of the loop.  For the overflow case, it would pass it
on as a bus error, which should then behave as expected.  Thoughts?

This, of course, is only necessary if there are ESP machines without
reconfigurable IRQ levels.  Does anybody know of such a board on mac68k?


> 3. I'm not sure if this will be a win on DMA machines. The way I'm 
> planning to do the DMA SCSI, the interrupt handlers will do very little 
> besides occasionally updating the DMA engine or clearing the SCSI 
> interrupts. There will be no "work" to do besides run through the SCSI 
> state machine at the end of the transfer. The ethernet driver, though, 
> could probably defer the copying of inbound data into mbufs until a 
> thread, however. Though, an even better solution would be to DMA 
> directly into the mbufs, but I can't think of how to do this without 
> taking an interrupt per-packet (though, we may already be doing that!)

Assuming you mean AMIC DMA off a MACE, I rather suspect you're going to
run into an alignment nightmare if you try to DMA directly into the
mbufs.  AMIC is a fun little spawn of satan....


> Overall, though, I would imagine this would improve the clock drift 
> situation. Still, it would be great if we could find a high resolution 
> free running counter somewhere. :(

Like PowerPC's TBR?


Later,
David

---------------------------------------------------------------------
David A. Gatwood                                dgatwood@gatwood.net
Developer Docs Writer                             dgatwood@apple.com
Apple Computer                                  dgatwood@mklinux.org

                    Check out my weekly web comic:
                     http://www.techmagazine.org