Re: Linux and real device drivers
Momchil Velikov (velco@fadata.bg)
Wed, 22 Sep 1999 15:22:04 +0300
Alan Cox wrote:
>
> > > 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.
> >
> > Are you kidding? Do you really want to use that on device's registers ?
>
> Thats how modern PCI cards work. It isnt as horrying as it sounds. the
> store buffer on PCI is ordered and reads don't occur until the store
> buffer is emptied - so ordering is preserved.
>
> If you look at something like I2O you will see that the whole setup is
> geared to posting. You post requests to the card, it posts replies to your
> memory. The only stall is getting a new message to fill.
>
> On the memory side you take a cache miss from the DMA from the card but
> on an AMD Athlon you can even prefetch that.
>
> > Note that this is unconditional branch, and if the branch target address
> > is computed sufficiently ahead of the branch instruction there will be
> > no penalty.
>
> There is the jump/return overhead. There is the stack management overhead
> There is an extra cache line touched.
Ok, folks, I think we are talking about "udi_pio_trans" call
(in UDI Physical I/O Specification) and this call is surely not meant
to perform a single I/O port or MMIO read/write. Instead the UDI
implementation executes a large transaction including many
reads, writes, arithmetic operations, branches, etc.
Now, the overhead is by no means in the call, it's in interpreting
the transaction description and I'd say yes, it ought to be rather big.
> > > documentation on the IA64 to see what we might expect from the future,
> > > branches are expensive.
> >
> > Have Intel released docs about some implementation of the architecture ?
>
> All the basic userland stuff is released. Its very pa-risc.
I've seen that one, I just think is too adventurous to judge about
branch performance based on an ISA spec.
Regards,
-velco
-
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/