linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shaohua Li <shaohua.li@intel.com>
To: axboe@kernel.dk
Cc: linux-kernel@vger.kernel.org, vgoyal@redhat.com,
	david@fromorbit.com, jack@suse.cz, zhu.yanhai@gmail.com,
	namhyung.kim@lge.com
Subject: Re: [patch v2 0/8]block: An IOPS based ioscheduler
Date: Mon, 30 Jan 2012 15:09:12 +0800	[thread overview]
Message-ID: <1327907352.21268.1.camel@sli10-conroe> (raw)
In-Reply-To: <20120130070213.793690895@sli10-conroe.sh.intel.com>

[-- Attachment #1: Type: text/plain, Size: 2677 bytes --]

On Mon, 2012-01-30 at 15:02 +0800, Shaohua Li wrote:
> An IOPS based I/O scheduler
> 
> Flash based storage has some different characteristics against rotate disk.
> 1. no I/O seek.
> 2. read and write I/O cost usually is much different.
> 3. Time which a request takes depends on request size.
> 4. High throughput and IOPS, low latency.
> 
> CFQ iosched does well for rotate disk, for example fair dispatching, idle
> for sequential read. It also has optimization for flash based storage (for
> item 1 above), but overall it's not designed for flash based storage. It's
> a slice based algorithm. Since flash based storage request cost is very
> low, and drive has big queue_depth is quite popular now which makes
> dispatching cost even lower, CFQ's slice accounting (jiffy based)
> doesn't work well. CFQ doesn't consider above item 2 & 3.
> 
> FIOPS (Fair IOPS) ioscheduler is trying to fix the gaps. It's IOPS based, so
> only targets for drive without I/O seek. It's quite similar like CFQ, but
> the dispatch decision is made according to IOPS instead of slice.
> 
> To illustrate the design goals, let's compare Noop and CFQ:
> Noop: best throughput; No fairness and high latency for sync.
> CFQ: lower throughput in some cases; fairness and low latency for sync.
> CFQ throughput is slow sometimes because it doesn't drive deep queue depth.
> FIOPS adopts some merits of CFQ, for example, fairness and bias sync workload.
> And it will be faster than CFQ in general.
> 
> Note, if workload iodepth is low, there is no way to maintain fairness without
> performance sacrifice. Neither with CFQ. In such case, FIOPS will choose to not
> lose performance because flash based storage is usually very fast and expensive,
> performance is more important.
> 
> The algorithm is simple. Drive has a service tree, and each task lives in
> the tree. The key into the tree is called vios (virtual I/O). Every request
> has vios, which is calculated according to its ioprio, request size and so
> on. Task's vios is the sum of vios of all requests it dispatches. FIOPS
> always selects task with minimum vios in the service tree and let the task
> dispatch request. The dispatched request's vios is then added to the task's
> vios and the task is repositioned in the sevice tree.
> 
> Benchmarks results:
> SSD I'm using: max throughput read: 250m/s; write: 80m/s. max IOPS for 4k
> request read 40k/s; write 20k/s
> Latency and fairness tests are done in a desktop with one SSD and kernel
> parameter mem=1G. I'll compare noop, cfq and fiops in such workload. The test
> script and result is attached. 
attached is the fio scripts I used for latency and fairness test and
data.

[-- Attachment #2: fiops-data.tgz --]
[-- Type: application/x-compressed-tar, Size: 14188 bytes --]

  parent reply	other threads:[~2012-01-30  7:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-30  7:02 [patch v2 0/8]block: An IOPS based ioscheduler Shaohua Li
2012-01-30  7:02 ` [patch v2 1/8]block: fiops ioscheduler core Shaohua Li
2012-01-30  7:02 ` [patch v2 2/8]block: fiops read/write request scale Shaohua Li
2012-01-30  7:02 ` [patch v2 3/8]block: fiops sync/async scale Shaohua Li
2012-01-30  7:02 ` [patch v2 4/8]block: fiops add ioprio support Shaohua Li
2012-01-30  7:02 ` [patch v2 5/8]block: fiops preserve vios key for deep queue depth workload Shaohua Li
2012-01-30  7:02 ` [patch v2 6/8]block: fiops bias sync workload Shaohua Li
2012-01-30  7:02 ` [patch v2 7/8]block: fiops add some trace information Shaohua Li
2012-01-30  7:02 ` [patch v2 8/8]block: fiops sync preempts async Shaohua Li
2012-01-30 11:53   ` Hillf Danton
2012-01-30  7:09 ` Shaohua Li [this message]
2012-01-30 15:30 ` [patch v2 0/8]block: An IOPS based ioscheduler Vivek Goyal
2012-01-31  0:50   ` Shaohua Li

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=1327907352.21268.1.camel@sli10-conroe \
    --to=shaohua.li@intel.com \
    --cc=axboe@kernel.dk \
    --cc=david@fromorbit.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namhyung.kim@lge.com \
    --cc=vgoyal@redhat.com \
    --cc=zhu.yanhai@gmail.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 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).