* [PATCH v3] documentation of mmc non-blocking request
@ 2011-07-05 19:43 ` Per Forlin
0 siblings, 0 replies; 10+ messages in thread
From: Per Forlin @ 2011-07-05 19:43 UTC (permalink / raw)
To: linaro-dev, Nicolas Pitre, linux-arm-kernel, linux-kernel,
linux-mmc, linux-doc, Venkatraman S, Linus Walleij,
Kyungmin Park, Arnd Bergmann, Sourav Poddar, Chris Ball
Cc: Randy Dunlap, Per Forlin
changes since v2:
* Minor updates after more comments from Chris
Per Forlin (1):
mmc: documentation of mmc non-blocking request usage and design.
Documentation/mmc/00-INDEX | 2 +
Documentation/mmc/mmc-async-req.txt | 86 +++++++++++++++++++++++++++++++++++
2 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 Documentation/mmc/mmc-async-req.txt
--
1.7.4.1
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v3] documentation of mmc non-blocking request
@ 2011-07-05 19:43 ` Per Forlin
0 siblings, 0 replies; 10+ messages in thread
From: Per Forlin @ 2011-07-05 19:43 UTC (permalink / raw)
To: linaro-dev, Nicolas Pitre, linux-arm-kernel, linux-kernel,
linux-mmc, linux-doc
Cc: Randy Dunlap, Per Forlin
changes since v2:
* Minor updates after more comments from Chris
Per Forlin (1):
mmc: documentation of mmc non-blocking request usage and design.
Documentation/mmc/00-INDEX | 2 +
Documentation/mmc/mmc-async-req.txt | 86 +++++++++++++++++++++++++++++++++++
2 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 Documentation/mmc/mmc-async-req.txt
--
1.7.4.1
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v3] documentation of mmc non-blocking request
@ 2011-07-05 19:43 ` Per Forlin
0 siblings, 0 replies; 10+ messages in thread
From: Per Forlin @ 2011-07-05 19:43 UTC (permalink / raw)
To: linux-arm-kernel
changes since v2:
* Minor updates after more comments from Chris
Per Forlin (1):
mmc: documentation of mmc non-blocking request usage and design.
Documentation/mmc/00-INDEX | 2 +
Documentation/mmc/mmc-async-req.txt | 86 +++++++++++++++++++++++++++++++++++
2 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 Documentation/mmc/mmc-async-req.txt
--
1.7.4.1
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v3] mmc: documentation of mmc non-blocking request usage and design.
2011-07-05 19:43 ` Per Forlin
(?)
@ 2011-07-05 19:43 ` Per Forlin
-1 siblings, 0 replies; 10+ messages in thread
From: Per Forlin @ 2011-07-05 19:43 UTC (permalink / raw)
To: linaro-dev, Nicolas Pitre, linux-arm-kernel, linux-kernel,
linux-mmc, linux-doc, Venkatraman S, Linus Walleij,
Kyungmin Park, Arnd Bergmann, Sourav Poddar, Chris Ball
Cc: Randy Dunlap, Per Forlin
Documentation about the background and the design of mmc non-blocking.
Host driver guidelines to minimize request preparation overhead.
Signed-off-by: Per Forlin <per.forlin@linaro.org>
---
Documentation/mmc/00-INDEX | 2 +
Documentation/mmc/mmc-async-req.txt | 86 +++++++++++++++++++++++++++++++++++
2 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 Documentation/mmc/mmc-async-req.txt
diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX
index 93dd7a7..11bc2cf 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 request
diff --git a/Documentation/mmc/mmc-async-req.txt b/Documentation/mmc/mmc-async-req.txt
new file mode 100644
index 0000000..d7e7698
--- /dev/null
+++ b/Documentation/mmc/mmc-async-req.txt
@@ -0,0 +1,86 @@
+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 to 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 is processing. Using non-blocking mmc requests makes it
+possible to prepare the caches for next job in parallel to an active
+mmc request.
+
+MMC block driver
+================
+
+The 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 is 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 to the transfer performance wont 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 on 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 hooks pre_req() and post_req() that the host driver
+may implement in order to move work to before and after the actual
+mmc_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 to
+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)
--
1.7.4.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH v3] mmc: documentation of mmc non-blocking request usage and design.
@ 2011-07-05 19:43 ` Per Forlin
0 siblings, 0 replies; 10+ messages in thread
From: Per Forlin @ 2011-07-05 19:43 UTC (permalink / raw)
To: linaro-dev, Nicolas Pitre, linux-arm-kernel, linux-kernel,
linux-mmc, linux-doc
Cc: Randy Dunlap, Per Forlin
Documentation about the background and the design of mmc non-blocking.
Host driver guidelines to minimize request preparation overhead.
Signed-off-by: Per Forlin <per.forlin@linaro.org>
---
Documentation/mmc/00-INDEX | 2 +
Documentation/mmc/mmc-async-req.txt | 86 +++++++++++++++++++++++++++++++++++
2 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 Documentation/mmc/mmc-async-req.txt
diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX
index 93dd7a7..11bc2cf 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 request
diff --git a/Documentation/mmc/mmc-async-req.txt b/Documentation/mmc/mmc-async-req.txt
new file mode 100644
index 0000000..d7e7698
--- /dev/null
+++ b/Documentation/mmc/mmc-async-req.txt
@@ -0,0 +1,86 @@
+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 to 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 is processing. Using non-blocking mmc requests makes it
+possible to prepare the caches for next job in parallel to an active
+mmc request.
+
+MMC block driver
+================
+
+The 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 is 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 to the transfer performance wont 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 on 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 hooks pre_req() and post_req() that the host driver
+may implement in order to move work to before and after the actual
+mmc_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 to
+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)
--
1.7.4.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH v3] mmc: documentation of mmc non-blocking request usage and design.
@ 2011-07-05 19:43 ` Per Forlin
0 siblings, 0 replies; 10+ messages in thread
From: Per Forlin @ 2011-07-05 19:43 UTC (permalink / raw)
To: linux-arm-kernel
Documentation about the background and the design of mmc non-blocking.
Host driver guidelines to minimize request preparation overhead.
Signed-off-by: Per Forlin <per.forlin@linaro.org>
---
Documentation/mmc/00-INDEX | 2 +
Documentation/mmc/mmc-async-req.txt | 86 +++++++++++++++++++++++++++++++++++
2 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 Documentation/mmc/mmc-async-req.txt
diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX
index 93dd7a7..11bc2cf 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 request
diff --git a/Documentation/mmc/mmc-async-req.txt b/Documentation/mmc/mmc-async-req.txt
new file mode 100644
index 0000000..d7e7698
--- /dev/null
+++ b/Documentation/mmc/mmc-async-req.txt
@@ -0,0 +1,86 @@
+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 to 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 is processing. Using non-blocking mmc requests makes it
+possible to prepare the caches for next job in parallel to an active
+mmc request.
+
+MMC block driver
+================
+
+The 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 is 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 to the transfer performance wont 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 on 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 hooks pre_req() and post_req() that the host driver
+may implement in order to move work to before and after the actual
+mmc_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 to
+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)
--
1.7.4.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v3] mmc: documentation of mmc non-blocking request usage and design.
2011-07-05 19:43 ` Per Forlin
@ 2011-07-05 20:27 ` Randy Dunlap
-1 siblings, 0 replies; 10+ messages in thread
From: Randy Dunlap @ 2011-07-05 20:27 UTC (permalink / raw)
To: Per Forlin
Cc: linaro-dev, Nicolas Pitre, linux-arm-kernel, linux-kernel,
linux-mmc, linux-doc, Venkatraman S, Linus Walleij,
Kyungmin Park, Arnd Bergmann, Sourav Poddar, Chris Ball
On Tue, 5 Jul 2011 21:43:28 +0200 Per Forlin wrote:
> Documentation about the background and the design of mmc non-blocking.
> Host driver guidelines to minimize request preparation overhead.
>
> Signed-off-by: Per Forlin <per.forlin@linaro.org>
> ---
It would be better to omit the introductory email and put all of its comments
in this one [PATCH] email.
> Documentation/mmc/00-INDEX | 2 +
> Documentation/mmc/mmc-async-req.txt | 86 +++++++++++++++++++++++++++++++++++
> 2 files changed, 88 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/mmc/mmc-async-req.txt
>
> diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX
> index 93dd7a7..11bc2cf 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 request
requests
> diff --git a/Documentation/mmc/mmc-async-req.txt b/Documentation/mmc/mmc-async-req.txt
> new file mode 100644
> index 0000000..d7e7698
> --- /dev/null
> +++ b/Documentation/mmc/mmc-async-req.txt
> @@ -0,0 +1,86 @@
> +Rationale
> +=========
> +
> +How significant is the cache maintenance overhead?
> +It depends, fast eMMC and multiple cache levels with speculative cache
It depends:
or
It depends. Fast
> +pre-fetch makes the cache overhead relatively significant. If the DMA
> +preparations for the next request are done in parallel to the current
with the current
> +transfer the DMA preparation overhead would not affect the MMC performance.
transfer,
> +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
mmc_wait_for_req(),
> +dma_unmap_sg is processing. Using non-blocking mmc requests makes it
are processing.
> +possible to prepare the caches for next job in parallel to an active
with an active
> +mmc request.
> +
> +MMC block driver
> +================
> +
> +The issue_rw_rq() in the mmc block driver is made non-blocking.
preferably: MMC
throughout the file (when not a function or data name, etc.)
> +The increase in throughput is proportional to the time it takes to
> +prepare (major part of preparations is dma_map_sg and dma_unmap_sg)
are
> +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 to the transfer performance wont be affected.
with won't
> +
> +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()
mmc_start_req().
> +It starts a new MMC command request for a host. The function isn't
> +truly non-blocking. If there is on 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 hooks pre_req() and post_req() that the host driver
hooks -- pre_req() and post_req() -- that
> +may implement in order to move work to before and after the actual
> +mmc_request function is called. In the DMA case pre_req() may do
> +dma_map_sg() and prepare the dma descriptor, and post_req runs
DMA
> +the dma_unmap_sg.
> +
> +Optimize for the first request
> +==============================
> +
> +The first request in a series of requests can't be prepared in parallel to
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)
Please use ';' at the end of each pseudo-call.
> +
> + /*
> + * 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)
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v3] mmc: documentation of mmc non-blocking request usage and design.
@ 2011-07-05 20:27 ` Randy Dunlap
0 siblings, 0 replies; 10+ messages in thread
From: Randy Dunlap @ 2011-07-05 20:27 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 5 Jul 2011 21:43:28 +0200 Per Forlin wrote:
> Documentation about the background and the design of mmc non-blocking.
> Host driver guidelines to minimize request preparation overhead.
>
> Signed-off-by: Per Forlin <per.forlin@linaro.org>
> ---
It would be better to omit the introductory email and put all of its comments
in this one [PATCH] email.
> Documentation/mmc/00-INDEX | 2 +
> Documentation/mmc/mmc-async-req.txt | 86 +++++++++++++++++++++++++++++++++++
> 2 files changed, 88 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/mmc/mmc-async-req.txt
>
> diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX
> index 93dd7a7..11bc2cf 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 request
requests
> diff --git a/Documentation/mmc/mmc-async-req.txt b/Documentation/mmc/mmc-async-req.txt
> new file mode 100644
> index 0000000..d7e7698
> --- /dev/null
> +++ b/Documentation/mmc/mmc-async-req.txt
> @@ -0,0 +1,86 @@
> +Rationale
> +=========
> +
> +How significant is the cache maintenance overhead?
> +It depends, fast eMMC and multiple cache levels with speculative cache
It depends:
or
It depends. Fast
> +pre-fetch makes the cache overhead relatively significant. If the DMA
> +preparations for the next request are done in parallel to the current
with the current
> +transfer the DMA preparation overhead would not affect the MMC performance.
transfer,
> +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
mmc_wait_for_req(),
> +dma_unmap_sg is processing. Using non-blocking mmc requests makes it
are processing.
> +possible to prepare the caches for next job in parallel to an active
with an active
> +mmc request.
> +
> +MMC block driver
> +================
> +
> +The issue_rw_rq() in the mmc block driver is made non-blocking.
preferably: MMC
throughout the file (when not a function or data name, etc.)
> +The increase in throughput is proportional to the time it takes to
> +prepare (major part of preparations is dma_map_sg and dma_unmap_sg)
are
> +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 to the transfer performance wont be affected.
with won't
> +
> +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()
mmc_start_req().
> +It starts a new MMC command request for a host. The function isn't
> +truly non-blocking. If there is on 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 hooks pre_req() and post_req() that the host driver
hooks -- pre_req() and post_req() -- that
> +may implement in order to move work to before and after the actual
> +mmc_request function is called. In the DMA case pre_req() may do
> +dma_map_sg() and prepare the dma descriptor, and post_req runs
DMA
> +the dma_unmap_sg.
> +
> +Optimize for the first request
> +==============================
> +
> +The first request in a series of requests can't be prepared in parallel to
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)
Please use ';' at the end of each pseudo-call.
> +
> + /*
> + * 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)
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3] mmc: documentation of mmc non-blocking request usage and design.
2011-07-05 20:27 ` Randy Dunlap
@ 2011-07-05 21:31 ` Per Forlin
-1 siblings, 0 replies; 10+ messages in thread
From: Per Forlin @ 2011-07-05 21:31 UTC (permalink / raw)
To: Randy Dunlap
Cc: linaro-dev, Nicolas Pitre, linux-arm-kernel, linux-kernel,
linux-mmc, linux-doc, Venkatraman S, Linus Walleij,
Kyungmin Park, Arnd Bergmann, Sourav Poddar, Chris Ball
On 5 July 2011 22:27, Randy Dunlap <rdunlap@xenotime.net> wrote:
> On Tue, 5 Jul 2011 21:43:28 +0200 Per Forlin wrote:
>
>> Documentation about the background and the design of mmc non-blocking.
>> Host driver guidelines to minimize request preparation overhead.
>>
>> Signed-off-by: Per Forlin <per.forlin@linaro.org>
>> ---
>
> It would be better to omit the introductory email and put all of its comments
> in this one [PATCH] email.
>
I agree. I'll put the changelog after "--" to exclude it from the
commit message.
All of your comments will be updated in v4.
Thanks for your comments,
Per
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v3] mmc: documentation of mmc non-blocking request usage and design.
@ 2011-07-05 21:31 ` Per Forlin
0 siblings, 0 replies; 10+ messages in thread
From: Per Forlin @ 2011-07-05 21:31 UTC (permalink / raw)
To: linux-arm-kernel
On 5 July 2011 22:27, Randy Dunlap <rdunlap@xenotime.net> wrote:
> On Tue, ?5 Jul 2011 21:43:28 +0200 Per Forlin wrote:
>
>> Documentation about the background and the design of mmc non-blocking.
>> Host driver guidelines to minimize request preparation overhead.
>>
>> Signed-off-by: Per Forlin <per.forlin@linaro.org>
>> ---
>
> It would be better to omit the introductory email and put all of its comments
> in this one [PATCH] email.
>
I agree. I'll put the changelog after "--" to exclude it from the
commit message.
All of your comments will be updated in v4.
Thanks for your comments,
Per
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-07-05 21:31 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-05 19:43 [PATCH v3] documentation of mmc non-blocking request Per Forlin
2011-07-05 19:43 ` Per Forlin
2011-07-05 19:43 ` Per Forlin
2011-07-05 19:43 ` [PATCH v3] mmc: documentation of mmc non-blocking request usage and design Per Forlin
2011-07-05 19:43 ` Per Forlin
2011-07-05 19:43 ` Per Forlin
2011-07-05 20:27 ` Randy Dunlap
2011-07-05 20:27 ` Randy Dunlap
2011-07-05 21:31 ` Per Forlin
2011-07-05 21:31 ` Per Forlin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.