linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Konstantin Dorfman <kdorfman@codeaurora.org>
To: cjb@laptop.org
Cc: tlinder@codeaurora.org, linux-mmc@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, merez@codeaurora.org,
	kdorfman@codeaurora.org
Subject: [RFC/PATCH] mmc: Add support to handle Urgent data transfer request
Date: Sun,  9 Jun 2013 18:48:55 +0300	[thread overview]
Message-ID: <1370792936-28812-1-git-send-email-kdorfman@codeaurora.org> (raw)

Motivation:

In order to decrease the latency of a prioritized request (such as READ
requests) the device driver might decide to stop the transmission of a
current "low priority" request in order to handle the "high priority" one.
The urgency of the request is decided by the block layer I/O scheduler.
When the block layer notifies the underlying device driver (eMMC for
example) of an urgent request, the device driver might decide to stop
the current request transmission. The remainder of the stopped request
will be re-inserted back to the scheduler, to be re-scheduled after
handling the urgent request.

This patch depends on following patches (in this order): 
1. [PATCH/RESEND v8 1/4] block: Add support for reinsert a dispatched req
2. [PATCH/RESEND v8 2/4] block: Extend cmd_flags in struct request
3. [PATCH v8 3/4] block: Add API for urgent request handling

In order to benefit in terms of read request latency I/O scheduler
should implement urgent request classify and schedule policy, like one
implemented by: 
	[PATCH v6 0/3] block: Adding ROW scheduling algorithm
	by Tanya Brokhman <tlinder@codeaurora.org> tlinder@codeaurora.org

These patches are introducing a new api's of the block layer, supporting
its ability to classify incoming requests as urgent:
 - blk_urgent_request()   - set a notifier function, which will be called upon
			    urgent request arraiving at block layer
 - blk_reinsert_request() - used to re-insert back request unserved by
			    MMC requests

Besides block layer dependencies, following eMMC device and host controller
capabilities needed:
 - eMMC card HPI functionality to be able to interrupt undergoing write request
 - stop_request() api implemented by host controller driver to correctly stop
   undergoing write transaction
 - MMC_CAP2_STOP_REQUEST capability bit used to enable/disable the feature

The change extends existing MMC layer wait event functionality, that was
introduced by following commit:

6035d97 mmc: fix async request mechanism for sequential read scenarios

Test was done with kernel 3.4 on msm platform.  Latency measured using
blktrace and custom instrumentation. Test was running parallel
read/write lmdd stream. Latency is measured in ms. CFQ scheduler used as
baseline, compared with ROW scheduler with the feature turned on.

Parallel lmdd:
./data/lmdd if=internal of=/data/write.dat bs=128k count=2500 sync=1
./data/lmdd of=internal if=/data/readfile.dat bs=128k count=2500

        Throughput [Mb/sec]  Worst latency [msec]
        read     write       read     write
ROW     150      40          55       3800
CFQ     134      40          500      3280

Above is the average of 5 runs. Resulting worst case latency improved by
factor 9.

Konstantin Dorfman (1):
  mmc: Add support to handle Urgent data transfer request

 drivers/mmc/card/block.c |  151 +++++++++++++++++++++++++++++++++-
 drivers/mmc/card/queue.c |   54 ++++++++++++-
 drivers/mmc/card/queue.h |    5 +-
 drivers/mmc/core/core.c  |  208 ++++++++++++++++++++++++++++++++++++++++++++--
 include/linux/mmc/card.h |    5 +-
 include/linux/mmc/host.h |   16 ++++-
 include/linux/mmc/mmc.h  |    1 +
 7 files changed, 425 insertions(+), 15 deletions(-)

--
1.7.6
--
Konstantin Dorfman,
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center,
Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

             reply	other threads:[~2013-06-09 15:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-09 15:48 Konstantin Dorfman [this message]
2013-06-09 15:48 ` [RFC/PATCH] mmc: Add support to handle Urgent data transfer request Konstantin Dorfman

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=1370792936-28812-1-git-send-email-kdorfman@codeaurora.org \
    --to=kdorfman@codeaurora.org \
    --cc=cjb@laptop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=merez@codeaurora.org \
    --cc=tlinder@codeaurora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).