On Sat, Nov 28, 1998 at 12:54:49PM +0100, Kurt Garloff wrote: > I implemented a polling mechansim similar to the other AM53C974 driver's, but > SMP-safe, which is disabled by default, as the code is ugly. (It has to be.) > Please, if you successfully tested 2.0c3, recompile with -DDC390_POLL_IRQ to > enable the polling mechanism for the multibyte messages and get a little > performance enhancement and tell me whether it works. > > (If you remember polling is bad and slow, you're not wrong. Defining > DC390_POLL_IRQ does not result in the driver using polling for normal > communication, however. It just avoid generating an IRQ in a situation, > where we exactly know another byte is there. This won't fail unless you > device is very very very buggy. And then you will see a Message: "DC390: > Deadlock in poll_irq!!" and the driver will try to continue.) Some good news: I changed my SCSI setup, again, and I'm able to test the AM53C974 with my harddisks. Well, let me tell you about the optional DC390_POLL_IRQ feature. In 2.0c3 it didn't work, cause the AM53C974 generates more interrupts than I expected. I fixed this in 2.0c4, and DC390_POLL_IRQ works there. Now the bad news: It takes some time (100us) until the next message bytes arrive, so there's no measurable performance gain. The numbers rather indicate a very slight decrease. Seems the (return from IRQ, do some other things, IRQ, read message next byte ) sequence is better than the polling for the next byte. So the CPU is able to do some useful things in the meantime and the kernel is unlocked. (Having thekernel locked is always bad!) I really expected the next message bytes to arrive much more quickly; the DC390_POLL_IRQ feature would have shown some benefits then. It might still be a good idea to use it on a very slow machine which needs more time to return from the IRQ and reentering than it takes waiting for the next byte. But extrapolating from what I have seen, a 386-DX25 might meet this statement. There are no 386s with PCI, AFAIK, so I will remove the (optional) DC390_POLL_IRQ from the driver in one of the next revisions. You can safely play with it in 2.0c4, but don't expect any performance gain. It is still disabled by default, of course, so you have to compiole with -DDC390_POLL_IRQ, if you to test it. BTW: Script processing SCSI controllers (such as ncr53c8xx or aic7xxx) have a significant advantage, here. You can built the knowledge of the SCSI messages lengths into the script. (There are other advantages, too, of course.) I'm still waiting for reports about 2.0c3 and/or c4 ... I'd like to release 2.0d and send it to Linus and Alan. Regards, -- Kurt Garloff <[EMAIL PROTECTED]> (Dortmund, FRG) PGP key on http://student.physik.uni-dortmund.de/homepages/garloff The second clause "open source code of derivative works" has been the most controversial (and, potentially the most successful) aspect of CopyLeft licensing. -- Halloween Document - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
