All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kyungmin Park <kmpark@infradead.org>
To: Per Forlin <per.forlin@linaro.org>
Cc: linaro-dev@lists.linaro.org,
	Nicolas Pitre <nicolas.pitre@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
	Nickolay Nickolaev <nicknickolaev@gmail.com>,
	Venkatraman S <svenkatr@ti.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Chris Ball <cjb@laptop.org>
Subject: Re: [PATCH v8 00/12] use nonblock mmc requests to minimize latency
Date: Tue, 28 Jun 2011 18:54:50 +0900	[thread overview]
Message-ID: <BANLkTinzOj-Uw3o__2=kHYqHwMW1BtAktQ@mail.gmail.com> (raw)
In-Reply-To: <1309248717-14606-1-git-send-email-per.forlin@linaro.org>

This patches are tested on samsung exynos4 platform.

Acked-by: Kyungmin Park <kyungmin.park@samsung.com>

On Tue, Jun 28, 2011 at 5:11 PM, Per Forlin <per.forlin@linaro.org> 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 non-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 non-blocking mmc request makes it
> possible to prepare the caches for next job in parallel to an active
> mmc request.
>
> This is done by making the issue_rw_rq() 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. Measurements on U5500
> and Panda on eMMC and SD shows significant performance gain 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
>
> Changes since v7:
>  * rebase on mmc-next, on top of Russell's updated error handling.
>  * Clarify description of mmc_start_req()
>  * Resolve compile without CONFIG_DMA_ENIGNE issue for mmci
>  * Add mmc test to measure how performance is affected by sg length
>  * Add missing wait_for_busy in mmc_test non-blocking test. This call got lost
>   in v4 of this patchset when refactoring mmc_start_req.
>  * Add sub-prefix (core block queue) to relevant patches.
>
> Per Forlin (12):
>  mmc: core: add non-blocking mmc request function
>  omap_hsmmc: add support for pre_req and post_req
>  mmci: implement pre_req() and post_req()
>  mmc: mmc_test: add debugfs file to list all tests
>  mmc: mmc_test: add test for non-blocking transfers
>  mmc: mmc_test: test to measure how sg_len affect performance
>  mmc: block: add member in mmc queue struct to hold request data
>  mmc: block: add a block request prepare function
>  mmc: block: move error code in issue_rw_rq to a separate function.
>  mmc: queue: add a second mmc queue request member
>  mmc: core: add random fault injection
>  mmc: block: add handling for two parallel block requests in
>    issue_rw_rq
>
>  drivers/mmc/card/block.c      |  505 ++++++++++++++++++++++++-----------------
>  drivers/mmc/card/mmc_test.c   |  491 ++++++++++++++++++++++++++++++++++++++--
>  drivers/mmc/card/queue.c      |  184 ++++++++++------
>  drivers/mmc/card/queue.h      |   33 ++-
>  drivers/mmc/core/core.c       |  167 +++++++++++++-
>  drivers/mmc/core/debugfs.c    |    5 +
>  drivers/mmc/host/mmci.c       |  147 +++++++++++-
>  drivers/mmc/host/mmci.h       |    8 +
>  drivers/mmc/host/omap_hsmmc.c |   87 +++++++-
>  include/linux/mmc/core.h      |    6 +-
>  include/linux/mmc/host.h      |   24 ++
>  lib/Kconfig.debug             |   11 +
>  12 files changed, 1345 insertions(+), 323 deletions(-)
>
> --
> 1.7.4.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

WARNING: multiple messages have this Message-ID (diff)
From: Kyungmin Park <kmpark-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Per Forlin <per.forlin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Nicolas Pitre
	<nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
	linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v8 00/12] use nonblock mmc requests to minimize latency
Date: Tue, 28 Jun 2011 18:54:50 +0900	[thread overview]
Message-ID: <BANLkTinzOj-Uw3o__2=kHYqHwMW1BtAktQ@mail.gmail.com> (raw)
In-Reply-To: <1309248717-14606-1-git-send-email-per.forlin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

This patches are tested on samsung exynos4 platform.

Acked-by: Kyungmin Park <kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

On Tue, Jun 28, 2011 at 5:11 PM, Per Forlin <per.forlin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 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 non-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 non-blocking mmc request makes it
> possible to prepare the caches for next job in parallel to an active
> mmc request.
>
> This is done by making the issue_rw_rq() 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. Measurements on U5500
> and Panda on eMMC and SD shows significant performance gain 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
>
> Changes since v7:
>  * rebase on mmc-next, on top of Russell's updated error handling.
>  * Clarify description of mmc_start_req()
>  * Resolve compile without CONFIG_DMA_ENIGNE issue for mmci
>  * Add mmc test to measure how performance is affected by sg length
>  * Add missing wait_for_busy in mmc_test non-blocking test. This call got lost
>   in v4 of this patchset when refactoring mmc_start_req.
>  * Add sub-prefix (core block queue) to relevant patches.
>
> Per Forlin (12):
>  mmc: core: add non-blocking mmc request function
>  omap_hsmmc: add support for pre_req and post_req
>  mmci: implement pre_req() and post_req()
>  mmc: mmc_test: add debugfs file to list all tests
>  mmc: mmc_test: add test for non-blocking transfers
>  mmc: mmc_test: test to measure how sg_len affect performance
>  mmc: block: add member in mmc queue struct to hold request data
>  mmc: block: add a block request prepare function
>  mmc: block: move error code in issue_rw_rq to a separate function.
>  mmc: queue: add a second mmc queue request member
>  mmc: core: add random fault injection
>  mmc: block: add handling for two parallel block requests in
>    issue_rw_rq
>
>  drivers/mmc/card/block.c      |  505 ++++++++++++++++++++++++-----------------
>  drivers/mmc/card/mmc_test.c   |  491 ++++++++++++++++++++++++++++++++++++++--
>  drivers/mmc/card/queue.c      |  184 ++++++++++------
>  drivers/mmc/card/queue.h      |   33 ++-
>  drivers/mmc/core/core.c       |  167 +++++++++++++-
>  drivers/mmc/core/debugfs.c    |    5 +
>  drivers/mmc/host/mmci.c       |  147 +++++++++++-
>  drivers/mmc/host/mmci.h       |    8 +
>  drivers/mmc/host/omap_hsmmc.c |   87 +++++++-
>  include/linux/mmc/core.h      |    6 +-
>  include/linux/mmc/host.h      |   24 ++
>  lib/Kconfig.debug             |   11 +
>  12 files changed, 1345 insertions(+), 323 deletions(-)
>
> --
> 1.7.4.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

WARNING: multiple messages have this Message-ID (diff)
From: kmpark@infradead.org (Kyungmin Park)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 00/12] use nonblock mmc requests to minimize latency
Date: Tue, 28 Jun 2011 18:54:50 +0900	[thread overview]
Message-ID: <BANLkTinzOj-Uw3o__2=kHYqHwMW1BtAktQ@mail.gmail.com> (raw)
In-Reply-To: <1309248717-14606-1-git-send-email-per.forlin@linaro.org>

This patches are tested on samsung exynos4 platform.

Acked-by: Kyungmin Park <kyungmin.park@samsung.com>

On Tue, Jun 28, 2011 at 5:11 PM, Per Forlin <per.forlin@linaro.org> 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 non-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 non-blocking mmc request makes it
> possible to prepare the caches for next job in parallel to an active
> mmc request.
>
> This is done by making the issue_rw_rq() 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. Measurements on U5500
> and Panda on eMMC and SD shows significant performance gain 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
>
> Changes since v7:
> ?* rebase on mmc-next, on top of Russell's updated error handling.
> ?* Clarify description of mmc_start_req()
> ?* Resolve compile without CONFIG_DMA_ENIGNE issue for mmci
> ?* Add mmc test to measure how performance is affected by sg length
> ?* Add missing wait_for_busy in mmc_test non-blocking test. This call got lost
> ? in v4 of this patchset when refactoring mmc_start_req.
> ?* Add sub-prefix (core block queue) to relevant patches.
>
> Per Forlin (12):
> ?mmc: core: add non-blocking mmc request function
> ?omap_hsmmc: add support for pre_req and post_req
> ?mmci: implement pre_req() and post_req()
> ?mmc: mmc_test: add debugfs file to list all tests
> ?mmc: mmc_test: add test for non-blocking transfers
> ?mmc: mmc_test: test to measure how sg_len affect performance
> ?mmc: block: add member in mmc queue struct to hold request data
> ?mmc: block: add a block request prepare function
> ?mmc: block: move error code in issue_rw_rq to a separate function.
> ?mmc: queue: add a second mmc queue request member
> ?mmc: core: add random fault injection
> ?mmc: block: add handling for two parallel block requests in
> ? ?issue_rw_rq
>
> ?drivers/mmc/card/block.c ? ? ?| ?505 ++++++++++++++++++++++++-----------------
> ?drivers/mmc/card/mmc_test.c ? | ?491 ++++++++++++++++++++++++++++++++++++++--
> ?drivers/mmc/card/queue.c ? ? ?| ?184 ++++++++++------
> ?drivers/mmc/card/queue.h ? ? ?| ? 33 ++-
> ?drivers/mmc/core/core.c ? ? ? | ?167 +++++++++++++-
> ?drivers/mmc/core/debugfs.c ? ?| ? ?5 +
> ?drivers/mmc/host/mmci.c ? ? ? | ?147 +++++++++++-
> ?drivers/mmc/host/mmci.h ? ? ? | ? ?8 +
> ?drivers/mmc/host/omap_hsmmc.c | ? 87 +++++++-
> ?include/linux/mmc/core.h ? ? ?| ? ?6 +-
> ?include/linux/mmc/host.h ? ? ?| ? 24 ++
> ?lib/Kconfig.debug ? ? ? ? ? ? | ? 11 +
> ?12 files changed, 1345 insertions(+), 323 deletions(-)
>
> --
> 1.7.4.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

  parent reply	other threads:[~2011-06-28  9:55 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-28  8:11 [PATCH v8 00/12] use nonblock mmc requests to minimize latency Per Forlin
2011-06-28  8:11 ` Per Forlin
2011-06-28  8:11 ` Per Forlin
2011-06-28  8:11 ` [PATCH v8 01/12] mmc: core: add non-blocking mmc request function Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11 ` [PATCH v8 02/12] omap_hsmmc: add support for pre_req and post_req Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11 ` [PATCH v8 03/12] mmci: implement pre_req() and post_req() Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11 ` [PATCH v8 04/12] mmc: mmc_test: add debugfs file to list all tests Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11 ` [PATCH v8 05/12] mmc: mmc_test: add test for non-blocking transfers Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-07-01 13:29   ` Per Forlin
2011-07-01 13:29     ` Per Forlin
2011-07-01 13:29     ` Per Forlin
2011-06-28  8:11 ` [PATCH v8 06/12] mmc: mmc_test: test to measure how sg_len affect performance Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-07-01 13:33   ` Per Forlin
2011-07-01 13:33     ` Per Forlin
2011-07-01 13:33     ` Per Forlin
2011-06-28  8:11 ` [PATCH v8 07/12] mmc: block: add member in mmc queue struct to hold request data Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11 ` [PATCH v8 08/12] mmc: block: add a block request prepare function Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11 ` [PATCH v8 09/12] mmc: block: move error code in issue_rw_rq to a separate function Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11 ` [PATCH v8 10/12] mmc: queue: add a second mmc queue request member Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11 ` [PATCH v8 11/12] mmc: core: add random fault injection Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11 ` [PATCH v8 12/12] mmc: block: add handling for two parallel block requests in issue_rw_rq Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  8:11   ` Per Forlin
2011-06-28  9:39   ` Per Forlin
2011-06-28  9:39     ` Per Forlin
2011-06-28  9:39     ` Per Forlin
2011-06-28  9:54 ` Kyungmin Park [this message]
2011-06-28  9:54   ` [PATCH v8 00/12] use nonblock mmc requests to minimize latency Kyungmin Park
2011-06-28  9:54   ` Kyungmin Park
2011-06-30 12:36 ` Poddar, Sourav
2011-06-30 12:36   ` Poddar, Sourav
2011-06-30 13:11   ` S, Venkatraman
2011-06-30 13:11     ` S, Venkatraman
2011-06-30 13:12 ` Arnd Bergmann
2011-06-30 13:12   ` Arnd Bergmann
2011-06-30 13:30   ` Russell King - ARM Linux
2011-06-30 13:30     ` Russell King - ARM Linux
2011-07-01 16:44     ` Arnd Bergmann
2011-07-01 16:44       ` Arnd Bergmann
2011-07-02 12:29       ` Russell King - ARM Linux
2011-07-02 12:29         ` Russell King - ARM Linux
2011-07-02 19:37         ` Arnd Bergmann
2011-07-02 19:37           ` Arnd Bergmann
2011-07-03 20:53           ` Per Forlin
2011-07-03 20:53             ` Per Forlin
2011-07-04  1:07             ` Nicolas Pitre
2011-07-04  1:07               ` Nicolas Pitre
2011-07-01 14:39 ` Linus Walleij
2011-07-01 14:39   ` Linus Walleij

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='BANLkTinzOj-Uw3o__2=kHYqHwMW1BtAktQ@mail.gmail.com' \
    --to=kmpark@infradead.org \
    --cc=cjb@laptop.org \
    --cc=linaro-dev@lists.linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=nicknickolaev@gmail.com \
    --cc=nicolas.pitre@linaro.org \
    --cc=per.forlin@linaro.org \
    --cc=svenkatr@ti.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.