linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tanya Brokhman <tlinder@codeaurora.org>
To: axboe@kernel.dk
Cc: linux-arm-msm@vger.kernel.org, linux-mmc@vger.kernel.org,
	Tanya Brokhman <tlinder@codeaurora.org>
Subject: [RFC/PATCH v2 0/4] block: Add support for urgent request handling in CFQ
Date: Fri, 12 Jul 2013 20:05:58 +0300	[thread overview]
Message-ID: <1373648759-16875-1-git-send-email-tlinder@codeaurora.org> (raw)

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.

The above is implemented in the block layer by 2 callbacks of the queue:
- urgent_request_fn() - This callback is registered by the underlying
  device driver and is called instead of the existing requst_fn() callbacks
  to handle urgent requests.
- elevator_is_urgent_fn() - This callback is registered by the current
  I/O scheduler. If present it's used by the block layer to ping the
  scheduler of an urgent request presence.           
NOTE: If one of the above callbacks is not registered, these code pass
will never be activated.

This patch set adds support for urgent request handling to the CFQ I/O
scheduler as an example. Using the urgent request notification together
with support from the underling device driver improves both the throughput
and the worst case latency of READ requests in READ and WRITE collision
scenarios.

For example, the bellow numbers were collected for  parallel lmdd read and
write. The tests were performed on:
kernel version: 3.4
Underline device driver: mmc
Host controller: msm-sdhci
Card: standard emmc NAND flash

-------------------------------------------------------------------
   Algorithm   |   Throughput [mb/sec]   |   Worst case Latency   |
               |     READ    |   WRITE   |   READ Latency [msec]  |
-------------------------------------------------------------------
original CFQ   |    119      |   39      |         597            |
CFQ with urgent|    	     |           |                        |
notification   |    150      |   37      |         35             |
support	       |	     |		 |			  |

This development depends on a patch introduced by Jens Axboe in
linux-block git tree which extends the req->cmd_flags field.
It's attached to this patch set for convenience.

Jens Axboe (1):
  block: make rq->cmd_flags be 64-bit

Tanya Brokhman (3):
  block: Add support for reinsert a dispatched req
  block: Add API for URGENT request handling
  block: Add URGENT request notification support to CFQ scheduler

 block/blk-core.c          |   89 ++++++++++++++++++++++++++++++++++-----
 block/blk-settings.c      |   12 +++++
 block/cfq-iosched.c       |  101 ++++++++++++++++++++++++++++++++++++++++++--
 block/elevator.c          |   39 +++++++++++++++++
 drivers/block/floppy.c    |    4 +-
 drivers/scsi/sd.c         |    2 +-
 include/linux/blk_types.h |   68 +++++++++++++++---------------
 include/linux/blkdev.h    |   10 ++++-
 include/linux/elevator.h  |    7 +++
 9 files changed, 278 insertions(+), 54 deletions(-)

-- 
1.7.6

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

                 reply	other threads:[~2013-07-12 17:06 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1373648759-16875-1-git-send-email-tlinder@codeaurora.org \
    --to=tlinder@codeaurora.org \
    --cc=axboe@kernel.dk \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.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).