From: Jaehoon Chung <jh80.chung@samsung.com>
To: Philip Rakity <prakity@marvell.com>
Cc: Per Forlin <per.forlin@linaro.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
Chris Ball <cjb@laptop.org>
Subject: Re: [PATCH v3 00/12] mmc: use nonblock mmc requests to minimize latency
Date: Thu, 12 May 2011 13:28:09 +0900 [thread overview]
Message-ID: <4DCB61D9.5050508@samsung.com> (raw)
In-Reply-To: <5D6BC6C8-D3C6-4987-B8AF-523A500D8309@marvell.com>
Hi Philip..
I have something question..did you test SDMA and ADMA?
Actually i didn't test [patch v3] but i tested patch v2 before Per sent.
I got that SDMA is faster than ADMA. (using bounce buffer and sdhci)
How do you think about that? I want to know your thought.
And if you can share the results, i want to know them.
Regards,
Jaehoon Chung
Philip Rakity wrote:
> On May 9, 2011, at 5:34 AM, Per Forlin wrote:
>
>> On 9 May 2011 04:05, Philip Rakity <prakity@marvell.com> wrote:
>>> Hi Per,
>>>
>>> We noticed on some of our systems if we ADMA or SDMA and a bounce buffer it is significantly faster then SDMA.
>>>
>> I have not done work with ADMA or SDMA. Where should I look to read
>> more about it?
>> Are these the right places. DMA iop-dma.c and imx-sdma.c, MMC: sdhci.c.
>
> sdhci.c for ADMA and SDMA
>
> spec is at
> http://www.sdcard.org/developers/tech/sdcard/pls/simplified_specs/
>
> version 3 discusses ADMA
>
>>> I believe ADMA will do large transfers. Another data point.
>>>
>>> Philip
>> Thanks,
>> Per
>>
>>> On May 7, 2011, at 12:14 PM, Per Forlin wrote:
>>>
>>>> How significant is the cache maintenance over head?
>>>> It depends, the eMMC are much faster now
>>>> compared to a few years ago and cache maintenance cost more due to
>>>> multiple cache levels and speculative cache pre-fetch. In relation the
>>>> cost for handling the caches have increased and is now a bottle neck
>>>> dealing with fast eMMC together with DMA.
>>>>
>>>> The intention for introducing none blocking mmc requests is to minimize the
>>>> time between a mmc request ends and another mmc request starts. In the
>>>> current implementation the MMC controller is idle when dma_map_sg and
>>>> dma_unmap_sg is processing. Introducing none blocking mmc request makes it
>>>> possible to prepare the caches for next job parallel with an active
>>>> mmc request.
>>>>
>>>> This is done by making the issue_rw_rq() none 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. Measurements on U5500
>>>> and Panda on eMMC and SD shows significant performance gain for for large
>>>> reads when running DMA mode. In the PIO case the performance is unchanged.
>>>>
>>>> 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.
>>>>
>>>> Details on measurements from IOZone and mmc_test:
>>>> https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req
>>>>
>>>> Under consideration:
>>>> * Make pre_req and post_req private to core.c.
>>>> * Generalize implementation and make it available for SDIO.
>>>>
>>>> Changes since v2:
>>>> * Fix compile warnings in core.c and block.c
>>>> * Simplify max transfer size in mmc_test
>>>> * set TASK_RUNNING in queue.c before issue_req()
>>>>
>>>> Per Forlin (12):
>>>> mmc: add none blocking mmc request function
>>>> mmc: mmc_test: add debugfs file to list all tests
>>>> mmc: mmc_test: add test for none blocking transfers
>>>> mmc: add member in mmc queue struct to hold request data
>>>> mmc: add a block request prepare function
>>>> mmc: move error code in mmc_block_issue_rw_rq to a separate function.
>>>> mmc: add a second mmc queue request member
>>>> mmc: add handling for two parallel block requests in issue_rw_rq
>>>> mmc: test: add random fault injection in core.c
>>>> omap_hsmmc: use original sg_len for dma_unmap_sg
>>>> omap_hsmmc: add support for pre_req and post_req
>>>> mmci: implement pre_req() and post_req()
>>>>
>>>> drivers/mmc/card/block.c | 493 +++++++++++++++++++++++++++--------------
>>>> drivers/mmc/card/mmc_test.c | 340 +++++++++++++++++++++++++++-
>>>> drivers/mmc/card/queue.c | 180 ++++++++++------
>>>> drivers/mmc/card/queue.h | 31 ++-
>>>> drivers/mmc/core/core.c | 132 ++++++++++-
>>>> drivers/mmc/core/debugfs.c | 5 +
>>>> drivers/mmc/host/mmci.c | 146 +++++++++++-
>>>> drivers/mmc/host/mmci.h | 8 +
>>>> drivers/mmc/host/omap_hsmmc.c | 90 +++++++-
>>>> include/linux/mmc/core.h | 9 +-
>>>> include/linux/mmc/host.h | 13 +-
>>>> lib/Kconfig.debug | 11 +
>>>> 12 files changed, 1174 insertions(+), 284 deletions(-)
>>>>
>>>> --
>>>> 1.7.4.1
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
WARNING: multiple messages have this Message-ID (diff)
From: jh80.chung@samsung.com (Jaehoon Chung)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 00/12] mmc: use nonblock mmc requests to minimize latency
Date: Thu, 12 May 2011 13:28:09 +0900 [thread overview]
Message-ID: <4DCB61D9.5050508@samsung.com> (raw)
In-Reply-To: <5D6BC6C8-D3C6-4987-B8AF-523A500D8309@marvell.com>
Hi Philip..
I have something question..did you test SDMA and ADMA?
Actually i didn't test [patch v3] but i tested patch v2 before Per sent.
I got that SDMA is faster than ADMA. (using bounce buffer and sdhci)
How do you think about that? I want to know your thought.
And if you can share the results, i want to know them.
Regards,
Jaehoon Chung
Philip Rakity wrote:
> On May 9, 2011, at 5:34 AM, Per Forlin wrote:
>
>> On 9 May 2011 04:05, Philip Rakity <prakity@marvell.com> wrote:
>>> Hi Per,
>>>
>>> We noticed on some of our systems if we ADMA or SDMA and a bounce buffer it is significantly faster then SDMA.
>>>
>> I have not done work with ADMA or SDMA. Where should I look to read
>> more about it?
>> Are these the right places. DMA iop-dma.c and imx-sdma.c, MMC: sdhci.c.
>
> sdhci.c for ADMA and SDMA
>
> spec is at
> http://www.sdcard.org/developers/tech/sdcard/pls/simplified_specs/
>
> version 3 discusses ADMA
>
>>> I believe ADMA will do large transfers. Another data point.
>>>
>>> Philip
>> Thanks,
>> Per
>>
>>> On May 7, 2011, at 12:14 PM, Per Forlin wrote:
>>>
>>>> How significant is the cache maintenance over head?
>>>> It depends, the eMMC are much faster now
>>>> compared to a few years ago and cache maintenance cost more due to
>>>> multiple cache levels and speculative cache pre-fetch. In relation the
>>>> cost for handling the caches have increased and is now a bottle neck
>>>> dealing with fast eMMC together with DMA.
>>>>
>>>> The intention for introducing none blocking mmc requests is to minimize the
>>>> time between a mmc request ends and another mmc request starts. In the
>>>> current implementation the MMC controller is idle when dma_map_sg and
>>>> dma_unmap_sg is processing. Introducing none blocking mmc request makes it
>>>> possible to prepare the caches for next job parallel with an active
>>>> mmc request.
>>>>
>>>> This is done by making the issue_rw_rq() none 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. Measurements on U5500
>>>> and Panda on eMMC and SD shows significant performance gain for for large
>>>> reads when running DMA mode. In the PIO case the performance is unchanged.
>>>>
>>>> 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.
>>>>
>>>> Details on measurements from IOZone and mmc_test:
>>>> https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req
>>>>
>>>> Under consideration:
>>>> * Make pre_req and post_req private to core.c.
>>>> * Generalize implementation and make it available for SDIO.
>>>>
>>>> Changes since v2:
>>>> * Fix compile warnings in core.c and block.c
>>>> * Simplify max transfer size in mmc_test
>>>> * set TASK_RUNNING in queue.c before issue_req()
>>>>
>>>> Per Forlin (12):
>>>> mmc: add none blocking mmc request function
>>>> mmc: mmc_test: add debugfs file to list all tests
>>>> mmc: mmc_test: add test for none blocking transfers
>>>> mmc: add member in mmc queue struct to hold request data
>>>> mmc: add a block request prepare function
>>>> mmc: move error code in mmc_block_issue_rw_rq to a separate function.
>>>> mmc: add a second mmc queue request member
>>>> mmc: add handling for two parallel block requests in issue_rw_rq
>>>> mmc: test: add random fault injection in core.c
>>>> omap_hsmmc: use original sg_len for dma_unmap_sg
>>>> omap_hsmmc: add support for pre_req and post_req
>>>> mmci: implement pre_req() and post_req()
>>>>
>>>> drivers/mmc/card/block.c | 493 +++++++++++++++++++++++++++--------------
>>>> drivers/mmc/card/mmc_test.c | 340 +++++++++++++++++++++++++++-
>>>> drivers/mmc/card/queue.c | 180 ++++++++++------
>>>> drivers/mmc/card/queue.h | 31 ++-
>>>> drivers/mmc/core/core.c | 132 ++++++++++-
>>>> drivers/mmc/core/debugfs.c | 5 +
>>>> drivers/mmc/host/mmci.c | 146 +++++++++++-
>>>> drivers/mmc/host/mmci.h | 8 +
>>>> drivers/mmc/host/omap_hsmmc.c | 90 +++++++-
>>>> include/linux/mmc/core.h | 9 +-
>>>> include/linux/mmc/host.h | 13 +-
>>>> lib/Kconfig.debug | 11 +
>>>> 12 files changed, 1174 insertions(+), 284 deletions(-)
>>>>
>>>> --
>>>> 1.7.4.1
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2011-05-12 4:28 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-07 19:14 [PATCH v3 00/12] mmc: use nonblock mmc requests to minimize latency Per Forlin
2011-05-07 19:14 ` Per Forlin
2011-05-07 19:14 ` [PATCH v3 01/12] mmc: add none blocking mmc request function Per Forlin
2011-05-07 19:14 ` Per Forlin
[not found] ` <1304795706-27308-1-git-send-email-per.forlin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2011-05-07 19:14 ` [PATCH v3 02/12] mmc: mmc_test: add debugfs file to list all tests Per Forlin
2011-05-07 19:14 ` Per Forlin
2011-05-07 19:14 ` Per Forlin
2011-05-07 22:18 ` Andy Shevchenko
2011-05-07 22:18 ` Andy Shevchenko
2011-05-08 13:12 ` Per Forlin
2011-05-08 13:12 ` Per Forlin
2011-05-07 19:14 ` [PATCH v3 03/12] mmc: mmc_test: add test for none blocking transfers Per Forlin
2011-05-07 19:14 ` Per Forlin
2011-05-07 19:14 ` Per Forlin
2011-05-07 19:14 ` [PATCH v3 04/12] mmc: add member in mmc queue struct to hold request data Per Forlin
2011-05-07 19:14 ` Per Forlin
2011-05-07 19:14 ` Per Forlin
2011-05-07 19:14 ` [PATCH v3 05/12] mmc: add a block request prepare function Per Forlin
2011-05-07 19:14 ` Per Forlin
2011-05-07 19:14 ` Per Forlin
2011-05-07 19:15 ` [PATCH v3 06/12] mmc: move error code in mmc_block_issue_rw_rq to a separate function Per Forlin
2011-05-07 19:15 ` Per Forlin
2011-05-07 19:15 ` Per Forlin
2011-05-07 19:15 ` [PATCH v3 07/12] mmc: add a second mmc queue request member Per Forlin
2011-05-07 19:15 ` Per Forlin
2011-05-07 19:15 ` Per Forlin
2011-05-07 19:15 ` [PATCH v3 08/12] mmc: add handling for two parallel block requests in issue_rw_rq Per Forlin
2011-05-07 19:15 ` Per Forlin
2011-05-07 19:15 ` Per Forlin
2011-05-07 19:15 ` [PATCH v3 09/12] mmc: test: add random fault injection in core.c Per Forlin
2011-05-07 19:15 ` Per Forlin
2011-05-07 19:15 ` Per Forlin
2011-05-07 19:15 ` [PATCH v3 10/12] omap_hsmmc: use original sg_len for dma_unmap_sg Per Forlin
2011-05-07 19:15 ` Per Forlin
2011-05-07 19:15 ` Per Forlin
2011-05-07 19:15 ` [PATCH v3 11/12] omap_hsmmc: add support for pre_req and post_req Per Forlin
2011-05-07 19:15 ` Per Forlin
2011-05-07 19:15 ` Per Forlin
2011-05-07 19:15 ` [PATCH v3 12/12] mmci: implement pre_req() and post_req() Per Forlin
2011-05-07 19:15 ` Per Forlin
2011-05-07 19:15 ` Per Forlin
2011-05-09 2:05 ` [PATCH v3 00/12] mmc: use nonblock mmc requests to minimize latency Philip Rakity
2011-05-09 2:05 ` Philip Rakity
2011-05-09 12:34 ` Per Forlin
2011-05-09 12:34 ` Per Forlin
2011-05-09 13:44 ` Philip Rakity
2011-05-09 13:44 ` Philip Rakity
2011-05-12 4:28 ` Jaehoon Chung [this message]
2011-05-12 4:28 ` Jaehoon Chung
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DCB61D9.5050508@samsung.com \
--to=jh80.chung@samsung.com \
--cc=cjb@laptop.org \
--cc=linaro-dev@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=per.forlin@linaro.org \
--cc=prakity@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.