diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2011-07-22 13:44:18 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2011-07-22 13:44:18 -0700 |
commit | 0df55ea55bf1f4827115af4740899980b4fce77f (patch) | |
tree | 1392b2c4b8d6758af933cc56586bb1396db7f3f3 /Documentation | |
parent | c1f792a5bfebcf7ee1d739c3cb9baeaede0160e7 (diff) | |
parent | d1057c40682990d29d4ee93d6ffd9836043552e6 (diff) |
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc: (78 commits)
mmc: MAINTAINERS: add myself as a tmio-mmc maintainer
mmc: print debug messages for runtime PM actions
mmc: fix runtime PM with -ENOSYS suspend case
mmc: at91_mci: move register header from include/ to drivers/
mmc: mxs-mmc: fix clock rate setting
mmc: tmio: fix a deadlock
mmc: tmio: fix a recently introduced bug in DMA code
mmc: sh_mmcif: maximize power saving
mmc: tmio: maximize power saving
mmc: tmio: fix recursive spinlock, don't schedule with interrupts disabled
mmc: Added quirks for Ricoh 1180:e823 lower base clock frequency
mmc: omap_hsmmc: fix oops in omap_hsmmc_dma_cb()
mmc: omap_hsmmc: refactor duplicated code
mmc: omap_hsmmc: fix a few bugs when setting the clock divisor
mmc: omap_hsmmc: introduce start_clock and re-use stop_clock
mmc: omap_hsmmc: split duplicate code to calc_divisor() function
mmc: omap_hsmmc: move hardcoded frequency constants to defines
mmc: omap_hsmmc: correct debug report error status mnemonics
mmc: block: fixed NULL pointer dereference
mmc: documentation of mmc non-blocking request usage and design.
...
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/mmc/00-INDEX | 2 | ||||
-rw-r--r-- | Documentation/mmc/mmc-async-req.txt | 87 |
2 files changed, 89 insertions, 0 deletions
diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX index 93dd7a71407..a9ba6720ffd 100644 --- a/Documentation/mmc/00-INDEX +++ b/Documentation/mmc/00-INDEX @@ -4,3 +4,5 @@ mmc-dev-attrs.txt - info on SD and MMC device attributes mmc-dev-parts.txt - info on SD and MMC device partitions +mmc-async-req.txt + - info on mmc asynchronous requests diff --git a/Documentation/mmc/mmc-async-req.txt b/Documentation/mmc/mmc-async-req.txt new file mode 100644 index 00000000000..ae1907b10e4 --- /dev/null +++ b/Documentation/mmc/mmc-async-req.txt @@ -0,0 +1,87 @@ +Rationale +========= + +How significant is the cache maintenance overhead? +It depends. Fast eMMC and multiple cache levels with speculative cache +pre-fetch makes the cache overhead relatively significant. If the DMA +preparations for the next request are done in parallel with the current +transfer, the DMA preparation overhead would not affect the MMC performance. +The intention of non-blocking (asynchronous) MMC requests is to minimize the +time between when an MMC request ends and another MMC request begins. +Using mmc_wait_for_req(), the MMC controller is idle while dma_map_sg and +dma_unmap_sg are processing. Using non-blocking MMC requests makes it +possible to prepare the caches for next job in parallel with an active +MMC request. + +MMC block driver +================ + +The mmc_blk_issue_rw_rq() in the MMC block driver is made non-blocking. +The increase in throughput is proportional to the time it takes to +prepare (major part of preparations are dma_map_sg() and dma_unmap_sg()) +a request and how fast the memory is. The faster the MMC/SD is the +more significant the prepare request time becomes. Roughly the expected +performance gain is 5% for large writes and 10% on large reads on a L2 cache +platform. In power save mode, when clocks run on a lower frequency, the DMA +preparation may cost even more. As long as these slower preparations are run +in parallel with the transfer performance won't be affected. + +Details on measurements from IOZone and mmc_test +================================================ + +https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req + +MMC core API extension +====================== + +There is one new public function mmc_start_req(). +It starts a new MMC command request for a host. The function isn't +truly non-blocking. If there is an ongoing async request it waits +for completion of that request and starts the new one and returns. It +doesn't wait for the new request to complete. If there is no ongoing +request it starts the new request and returns immediately. + +MMC host extensions +=================== + +There are two optional members in the mmc_host_ops -- pre_req() and +post_req() -- that the host driver may implement in order to move work +to before and after the actual mmc_host_ops.request() function is called. +In the DMA case pre_req() may do dma_map_sg() and prepare the DMA +descriptor, and post_req() runs the dma_unmap_sg(). + +Optimize for the first request +============================== + +The first request in a series of requests can't be prepared in parallel +with the previous transfer, since there is no previous request. +The argument is_first_req in pre_req() indicates that there is no previous +request. The host driver may optimize for this scenario to minimize +the performance loss. A way to optimize for this is to split the current +request in two chunks, prepare the first chunk and start the request, +and finally prepare the second chunk and start the transfer. + +Pseudocode to handle is_first_req scenario with minimal prepare overhead: + +if (is_first_req && req->size > threshold) + /* start MMC transfer for the complete transfer size */ + mmc_start_command(MMC_CMD_TRANSFER_FULL_SIZE); + + /* + * Begin to prepare DMA while cmd is being processed by MMC. + * The first chunk of the request should take the same time + * to prepare as the "MMC process command time". + * If prepare time exceeds MMC cmd time + * the transfer is delayed, guesstimate max 4k as first chunk size. + */ + prepare_1st_chunk_for_dma(req); + /* flush pending desc to the DMAC (dmaengine.h) */ + dma_issue_pending(req->dma_desc); + + prepare_2nd_chunk_for_dma(req); + /* + * The second issue_pending should be called before MMC runs out + * of the first chunk. If the MMC runs out of the first data chunk + * before this call, the transfer is delayed. + */ + dma_issue_pending(req->dma_desc); |