[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.999.0709181408390.16478@woody.linux-foundation.org>
Date: Tue, 18 Sep 2007 14:14:28 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Luis R. Rodriguez" <mcgrof@...il.com>
cc: Alan Cox <alan@...rguk.ukuu.org.uk>,
linux-kernel <linux-kernel@...r.kernel.org>,
Jeff Garzik <jeff@...zik.org>,
"John W. Linville" <linville@...driver.com>,
linux-wireless <linux-wireless@...r.kernel.org>
Subject: Re: [PATCH] Clarify pci_iomap() usage for MMIO-only devices
On Tue, 18 Sep 2007, Luis R. Rodriguez wrote:
>
> ACK but do we really need to benchmark this if we *know* we are
> creating unnecessary branches? How about Jeff's suggestion of
> introducing pci_mmio_map() ?
Here's the counter-argument:
- the run-time expense of this is basically *zero*
- the expense of badly written drivers is absolutely *huge*
The fewer "clever" interfaces we have for no good reason, and the less
unnecessary stuff that really doesn't matter, the more we help the
*second* case.
The fact is, for device drivers, the *true* performance issues are nowhere
*near* the actual IO accessor functions, and are all at a much higher
level for all but a very very limited set of drivers. And I think you're
making the important issues *worse*.
Really. "pci_mmio_map()" may not be a bad interface, but you're simply
working on entirely the wrong problem. The problem is not an out-of-line
IO accessor function - the problem is that you're making it even more
complicated to write drivers.
The whole point of the "iomap()" interface was *never* about making the
driver interfaces faster. It was about making them *cleaner*. And you're
screwing that up!
The old situation with SATA drivers that had
if (iomem)
writel(..)
else
outl(..)
in the cases that needed it (and used hardcoded writel/outl in the cases
that didn't) was an example of code that "in theory" is faster. But
dammit, in practice that mattered not one whit, and what iomap() tries to
do is to attack the _real_ problem we had in that area.
Which had nothing what-so-ever to do with any branches.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists