All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
	Nicolas Pitre <nicolas.pitre@linaro.org>,
	linaro-dev@lists.linaro.org,
	Linus Walleij <linus.walleij@linaro.org>,
	linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Chris Ball <cjb@laptop.org>, Per Forlin <per.forlin@linaro.org>,
	Nickolay Nickolaev <nicknickolaev@gmail.com>
Subject: Re: [PATCH v8 00/12] use nonblock mmc requests to minimize latency
Date: Sat, 2 Jul 2011 13:29:38 +0100	[thread overview]
Message-ID: <20110702122938.GI21898@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <201107011844.44058.arnd@arndb.de>

On Fri, Jul 01, 2011 at 06:44:43PM +0200, Arnd Bergmann wrote:
> On Thursday 30 June 2011, Russell King - ARM Linux wrote:
> > We've been here before - with PCMCIA's card insertion code, where you
> > have to go through a sequence of events (insert, power up, reset, etc).
> > The PCMCIA code used to have a collection of small functions to do
> > each step, one chained after the other in a state machine fashion.
> > The result was horrid.  That's exactly what you'll end up with here.
> > 
> > Threads have their place, and this is one of them.
> 
> Ok, fair enough. The performance enhancement is certainly here already
> with getting the cache management operations out of the hot path,
> and for the fully asynchronous case it's not getting better by trying
> to be smarter.
> 
> At least for ARM, the overhead of the DMA mapping operations will
> dwarf the overhead of the extra context switches for the foreseeable
> future, so we don't need to bother.
> 
> Things might be different for coherent low-end CPU cores like Atom
> when mmc device become much faster and block access becomes CPU
> bound.

One other thing to be considered here is whether this idea should be
limited to just MMC or whether it should be extended further, to
move the DMA mapping stuff out of the hot path for other block devices
too.

There are ARM systems with SATA which do 28MB/s - which could be
improved by this technique.


WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 00/12] use nonblock mmc requests to minimize latency
Date: Sat, 2 Jul 2011 13:29:38 +0100	[thread overview]
Message-ID: <20110702122938.GI21898@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <201107011844.44058.arnd@arndb.de>

On Fri, Jul 01, 2011 at 06:44:43PM +0200, Arnd Bergmann wrote:
> On Thursday 30 June 2011, Russell King - ARM Linux wrote:
> > We've been here before - with PCMCIA's card insertion code, where you
> > have to go through a sequence of events (insert, power up, reset, etc).
> > The PCMCIA code used to have a collection of small functions to do
> > each step, one chained after the other in a state machine fashion.
> > The result was horrid.  That's exactly what you'll end up with here.
> > 
> > Threads have their place, and this is one of them.
> 
> Ok, fair enough. The performance enhancement is certainly here already
> with getting the cache management operations out of the hot path,
> and for the fully asynchronous case it's not getting better by trying
> to be smarter.
> 
> At least for ARM, the overhead of the DMA mapping operations will
> dwarf the overhead of the extra context switches for the foreseeable
> future, so we don't need to bother.
> 
> Things might be different for coherent low-end CPU cores like Atom
> when mmc device become much faster and block access becomes CPU
> bound.

One other thing to be considered here is whether this idea should be
limited to just MMC or whether it should be extended further, to
move the DMA mapping stuff out of the hot path for other block devices
too.

There are ARM systems with SATA which do 28MB/s - which could be
improved by this technique.

  reply	other threads:[~2011-07-02 12:30 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 ` [PATCH v8 00/12] use nonblock mmc requests to minimize latency Kyungmin Park
2011-06-28  9:54   ` 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 [this message]
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=20110702122938.GI21898@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=arnd@arndb.de \
    --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 \
    /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.