On Tue, 30 Sep 2008 12:23:13 +0200
Christer Weinigel <[email protected]> wrote:
> Hi Pierre and anyone else who is interested,
>
Hi Christer,
> Here is a cleaned up patch that implements the low-latency SDIO stuff
> I mailed about a couple of weeks ago. Basically the patches adds
> asynchronous SDIO operations and makes it possible to register a
> "hard" SDIO interrupt handler which will be called directly from
> interrupt context (mmc_signal_sdio_irq).
>
> So, tell me what you think. :-)
>
Did you see the response I sent to the previous thread?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
Pierre Ossman wrote:
> On Tue, 30 Sep 2008 12:23:13 +0200
> Christer Weinigel <[email protected]> wrote:
>> Here is a cleaned up patch that implements the low-latency SDIO stuff
>> I mailed about a couple of weeks ago. Basically the patches adds
>> asynchronous SDIO operations and makes it possible to register a
>> "hard" SDIO interrupt handler which will be called directly from
>> interrupt context (mmc_signal_sdio_irq).
>
> Did you see the response I sent to the previous thread?
Yes, i think so. My previous post was mostly handwaving and some claims
of a performance improvement, I wanted to clean up my low latency
patches first and show a concrete implementation of what I was thinking
about before asking for more feedback.
This patch mostly adds things, the asynchronous API is available for for
those that need it, but old drivers will still work as before. There is
a difference for host drivers, drivers that sleep in their request
function will not work, but I believe request shouldn't do that anyway.
Anyway, is this the response you're thinking of:
September 5, Pierre Ossman wrote:
> The latency improvement is indeed impressive, but I am not convinced it
> is worth it. An asynchronous API is much more complex and difficult to
> work with (not to mention reading and trying to make sense of existing
> code), and SDIO is not even an asynchronous bus to begin with.
> I do like the idea of reducing latencies (and generally improving the
> performance of the MMC stack). The primary reason I haven't done
> anything myself is lack of stuff to test and proper instrumentation.
>
> There are really two issues here, which aren't necessarily related;
> actual interrupt latency and command completion latency.
>
> The main culprit in your case is the command completion one. Perhaps
> there is some other way of solving that inside the MMC core? E.g. we
> could spin instead of sleeping while we wait for the request to
> complete. Most drivers never use process context to handle a request
> anyway. We would need to determine when the request is small enough
> (all non-busy, non-data commands?) and that the CPU is slow enough. I
> also saw something about a new trigger interface that could make this
> efficient.
There are actually three issues I think, interrupt latency, command
completion latency, and CPU load.
Using a busy-wait for command completion would both reduce the load and
latency (because there will be no interrupt or wakeup overhead). But it
only helps for quick commands, for any commands that transfer data,
we'll have to use an interrupt and get the wakeup latencies. And for me
any latency, initial interrupt latency or latency after the data
transfer, are killers, so that's what I'm trying to solve.
I did google a bit for a Linux trigger interface and for some reason (I
can't remember exactly why now), I did not think that it would be
suitable for what I want to do.
So I still would like to get something like this low-latency thing into
the kernel.
/Christer