Documentation/mmc/mmc-async-req.txt

Chinese translated version of Documentation/mmc/mmc-async-req.txt

If you have any comment or update to the content, please contact the
original document maintainer directly.  However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help.  Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.

Chinese maintainer: keyingjing <342311642@qq.com>
---------------------------------------------------------------------
Documentation/mmc/mmc-async-req.txt 的中文翻译

如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。

中文版维护者： 柯莹璟  <342311642@qq.com>
中文版翻译者： 柯莹璟  <342311642@qq.com>
中文版校译者： 柯莹璟  <342311642@qq.com>

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.

基本原理
========
缓存维护开销有多重要？
这视情况而定。快速eMMC和多个级别的缓存使得投机缓存预取的开销相对比较显著。如果
DMA准备为并行完成下一个请求和当前的数据传输，DMA准备的开销不会影响MMC性能。非
阻塞（异步）MMC请求的意图是尽量减少一个MMC请求结束和另一个MMC请求开始之间的时间
间隔。使用函数mmc_wait_for_req()，当dma_map_sg 和 dma_unmap_sg处理时，MMC控制器
是空闲的。采用非阻塞的MMC请求，使得MMC控制器可以准备下一个作业缓存与活跃的MMC请求
并行。
 
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.

MMC块设备驱动程序

================
在MMC中的块驱动程序的mmc_blk_issue_rw_rq（）是非阻塞的。吞吐量的增加与准备的
请求时间（准备的主要组成部分是dma_map_sg()和dma_unmap_sg()）及存储器的速度成
正比。MMC/SD越快准备时间越显得重要。在L2缓冲平台大型写入中大致预期的性能增益
是5%，大型读入中增益10%。在省电模式下，当时钟在一个较低的频率运行时，DMA准备
工作可能会花费甚至更多的时间。只要这些较慢的准备工作与传输性能并行就不会受到
影响。

Details on measurements from IOZone and mmc_test
================================================
 https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req

对IOZone 和 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核心API扩展
==============
function mmc_start_req()是一个新的公共函数。它启动一个新的命令请求主机。该函数
不是真正的无阻塞。如果有一个正在进行的异步请求，需要等待完成该异步请求，才开始
新请求并返回。它不会等待新的请求来完成。如果没有正在进行的请求，就立即开始新请
求并返回。

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().
 
MMC主机扩展
===========
在mmc_host_ops中有两个可选成员——pre_req()和post_req()，以便主机驱动器可以实现在
调用mmc_host_ops.request()函数前后移动工作。在DMA情况下，pre_req()可以实现
dma_map_sg()并准备DMA描述符，post_req()运行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.

对第一个请求的优化
==================
一系列请求中的首请求因为缺少先前的请求，所以不能平行制备在以前的传输中。受争议
的是is_first_req在pre_req()中声明没有以前的请求。这种情况下，主机驱动器可以优化尽
可能减少性能损失。一种优化方法是将当前请求分割成两个快，制备第一个快然后启动请
求。最后制备第二个块并开始传输。
 
Pseudocode to handle is_first_req scenario with minimal prepare overhead:
下面是以最小准备开销处理is_first_req情景的伪代码：

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