On 09/30/2011 01:22 AM, Andrei E. Warkentin wrote:
Hi James,
2011/9/29 J Freyensee<james_p_freyen...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
