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/