Re: slow eMMC write speed

Andrei E. Warkentin
2011-09-30T08:22:37Z

Hi James,

2011/9/29 J Freyensee <james_p_freyensee@linux.intel.com>:
> As I've been playing around with with buffering/caching, it seems to me an
> opportunity to simplify things in the MMC space is to eliminate the need for
> a mmc_blk_request struct or mmc_request struct.  With looking through the
> mmc_blk_issue_rw_rq(), there is a lot of work to initialize struct
> mmc_blk_request brq, only to pass a struct mmc_queue variable the actual
> mmc_wait_for_req() instead.  In fact, some of the parameters in the struct
> mmc_blk_request member brq.mrq (of type mmc_request) wind up just pointing
> to members in struct mmc_blk_request brq.  Granted, I totally don't
> understand everything going on here and I haven't studied this code nearly
> as long as others, but when I see something like this, the first thing that
> comes up in my mind is 'elimination/simplification opportunity'.

mmc_request is what is actually handled by the SD/MMC host driver -
compact representation of
what needs to be done (unneeded fields are NULL pointers).
mmc_blk_request is basically the backing
store for these fields, for the block driver. I would guess the
mmc_request doesn't contain the fields
because it would be inefficient (or correct me). And since there is
quite a bit of logic behind running the
actual MMC commands (esp. w.r.t to mrq->sbc and mrq->stop), it would
not be a good idea to get
rid of mmc_request and pull the strings from card drivers either.

Praveen:

As for timings on Toshiba cards, you can search "MMC quirks relating
to performance/lifetime." in the archives.
There was quite a lot of very interesting data and discussions
specifically regarding performance, and it would
be pretty impossible and a disservice to try to summarize it :-). In
short, I've definitely seen 100ms blips, pronounced
by extra GC caused by unaligned accesses across allocation units (if I
remember correctly). You could try and reduce
the worst case, but it would make the average case worse. It's a bit
of voodoo. Best solution is interact with your vendor
and get suggestions on use and errata.

A