mirror of https://github.com/Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
98 lines
3.9 KiB
98 lines
3.9 KiB
======================== |
|
MMC Asynchronous Request |
|
======================== |
|
|
|
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);
|
|
|