Re: slow eMMC write speed

[Linus Walleij <linus.walleij@linaro.org>]

On Wed, Sep 28, 2011 at 11:34 PM, J Freyensee
<james_p_freyensee@linux.intel.com> wrote:

> Now in the 3.0 kernel I know mmc_wait_for_req() has changed and the goal was
> to try and make that function a bit more non-blocking,

What has been done by Per Förlin is to add pre_req/post_req hooks
for the datapath. This will improve data transfers in general if and
only if the driver can do some meaningful work in these hooks, so
your driver needs to be patched to use these.

Per patched a few select drivers to prepare the DMA buffers
at this time. In our case (mmci.c) dma_map_sg() can be done in
parallel with an ongoing transfer.

In our case (ux500, mmci, dma40) we don't have bounce buffers
so the only thing that will happen in parallel with ongoing transfers
is L2 and L1 cache flush. *still* we see a noticeable improvement in
throughput, most in L2, but even on the U300 which only does L1
cache I see some small improvements.

I *guess* if you're using bounce buffers, the gain will be even
more pronounced.

(Per, correct me if I'm wrong on any of this...)

> with it too much because my current focus is on existing products and no
> handheld product uses a 3.0 kernel yet (that I am aware of at least).
>  However, I still see the fundamental problem is that the MMC stack, which
> was probably written with the intended purpose to be independent of the OS
> block subsystem (struct request and other stuff), really isn't independent
> of the OS block subsystem and will cause holdups between one another,
> thereby dragging down read/write performance of the MMC.

There are two issues IIRC:

- The block layer does not provide enough buffers at a time for
  the out-of-order buffer pre/post preps to make effect, I think this
  was during writes only (Per, can you elaborate?)

- Anything related to card geometries and special sectors and
  sector sizes etc, i.e. the stuff that Arnd has analyzed in detail,
  also Tixy looked into that for some cards IIRC.

Each needs to be adressed and is currently "to be done".

> The other fundamental problem is the writes themselves.  Way, WAY more
> writes occur on a handheld system in an end-user's hands than reads.
> Fundamental computer principle states "you make the common case fast". So
> focus should be on how to complete a write operation the fastest way
> possible.

First case above I think, yep it needs looking into...

Yours,
Linus Walleij