Messages in this thread | | | Subject | Re: Linux and real device drivers | From | Jes Sorensen <> | Date | 22 Sep 1999 09:28:08 +0200 |
| |
>>>>> "Bret" == Bret Indrelee <breti@bit3.com> writes:
Bret> Jes Sorensen [mailto:Jes.Sorensen@cern.ch] wrote: >> Again, the last version of UDI I looked at was 0.80. Anyway, UDI >> means going through indirect functions to simply read/write a >> device register since you have no idea how a device is mapped in a >> certain type of machine or operating system .... this alone should >> be enough to prove my point.
Bret> It does prove a point, but maybe not the one you intended.
Oh yes it does.
Bret> PCI bus normally runs at 33 MHz. It takes at least two clock Bret> cycles to do a write and can take much longer to do a read. This Bret> gives us roughly 60 ns minimum for a write transaction during Bret> which time the CPU can do nothing. On a read, many PCI devices Bret> will send a RETRY signal just to give themselves more time. This Bret> can be more in the range of 100s of ns to single digit ms for a Bret> device read.
pre-fetching, write-back caching, nobody said all PCI writes have to be synchronous. No I don't really care about I/O port access.
Bret> Modern processors are in excess of 200 MHz. That would come out Bret> to about 5 ns/cycle. The processor can execute 12 instructions Bret> in the time it takes to do the minimum PCI cycle. That should be Bret> more than enough time to do a minimal subroutine call. The Bret> faster your processor, the worse it gets.
Faster your processor, the deeper your pipeline, branch == pipeline flush. next? And here you might want to look at some of the released documentation on the IA64 to see what we might expect from the future, branches are expensive.
Bret> The other point to keep in mind is that it is quite likely that Bret> NGIO will remove your ability to directly access those device Bret> registers. Since it moves to a channel architechure, any NGIO to Bret> PCI bridges are going to need code in order to allow you access Bret> to PCI I/O or memory space.
No lets wait and see if NGIO is going to be the bus of the future.
Bret> Now if we look at it from a system perspective, you can gain a Bret> lot more performance by making your mutexs work more Bret> efficiently.
That would of course be true if we needed the mutexes in this code path, and Linux mutexes are not exactly inefficient.
Bret> Looking at the SMP code in Linux, there is a large difference Bret> between what is required for doing spin_lock_irqsave() Bret> vs. spin_lock() for instance.
Hmmm maybe you should look at the code first, the difference between spin_lock() and spin_lock_irqsave() on the ia32 are three instructions.
Bret> Since the UDI layer would move almost all of the code out of the Bret> interrupt level, it is possible that a system would run faster Bret> using a UDI layer than the native LINUX drivers. In any event, Bret> it would be possible for the LINUX mutex and semaphore logic to Bret> change quite a bit without having to change any device drivers.
The UDI layer would not move all the parts of the code anywhere that requires the locking. The locking is generally not there to protect device register access, except for the cases where the hardware uses register windows, but to protect data structures in the driver. Besides, who says one necessarily needs to use spin locks and semaphores in interrupt handlers? Using sane hardware and a few tricks you often don't need any.
Jes
- 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/
| |