Re: slow eMMC write speed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/30/2011 01:22 AM, Andrei E. Warkentin wrote:
Hi James,

2011/9/29 J Freyensee<james_p_freyensee@xxxxxxxxxxxxxxx>:
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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux