Re: slow eMMC write speed

[J Freyensee <james_p_freyensee@linux.intel.com>]

On 09/30/2011 01:22 AM, Andrei E. Warkentin wrote:
> 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.

So I have a question on write behavior.

Say mmc_blk_issue_rw_rq() is called.  Say the mmc_queue *mq variable 
passed in is a write.  Say that write is buffered, delayed into being 
sent via mmc_wait_for_req() for 5 seconds, and it's sent to 
mmc_wait_for_req() later.  Would that delay of sending the brq->mrq 
entry to mmc_wait_for_req() cause a timeout, ie:

mmc0: Timeout waiting for hardware interrupt.

??

If this is true, how would you extend the timeout?  I would not have 
expected this until mmc_wait_for_req() is called.  It appeared to me 
mmc_set_data_timeout() was just setting a variable in brq to be used 
when mmc_wait_for_req() is called.  I only see this behavior in eMMC 
cards, not MMC cards being stuck into an MMC slot of a laptop.

Thanks!

>
> 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


-- 
J (James/Jay) Freyensee
Storage Technology Group
Intel Corporation