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, shaohua.li@intel.com
Subject: [patch v2 3/8]block: fiops sync/async scale
Date: Mon, 30 Jan 2012 15:02:16 +0800 [thread overview]
Message-ID: <20120130070634.587891025@sli10-conroe.sh.intel.com> (raw)
In-Reply-To: 20120130070213.793690895@sli10-conroe.sh.intel.com
[-- Attachment #1: fiops-sync-async-scale.patch --]
[-- Type: text/plain, Size: 2611 bytes --]
CFQ gives 2.5 times more share to sync workload. This matches CFQ.
Note this is different with the read/write scale. We have 3 types of
requests:
1. read
2. sync write
3. write
CFQ doesn't differentitate type 1 and 2, but request cost of 1 and 2
are usually different for flash based storage. So we have both sync/async
and read/write scale here.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
---
block/fiops-iosched.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
Index: linux/block/fiops-iosched.c
===================================================================
--- linux.orig/block/fiops-iosched.c 2012-01-18 14:33:51.000000000 +0800
+++ linux/block/fiops-iosched.c 2012-01-18 14:33:59.000000000 +0800
@@ -17,6 +17,8 @@
#define VIOS_READ_SCALE (1)
#define VIOS_WRITE_SCALE (1)
+#define VIOS_SYNC_SCALE (2)
+#define VIOS_ASYNC_SCALE (5)
struct fiops_rb_root {
struct rb_root rb;
@@ -39,6 +41,8 @@ struct fiops_data {
unsigned int read_scale;
unsigned int write_scale;
+ unsigned int sync_scale;
+ unsigned int async_scale;
};
struct fiops_ioc {
@@ -291,6 +295,9 @@ static u64 fiops_scaled_vios(struct fiop
if (rq_data_dir(rq) == WRITE)
vios = vios * fiopsd->write_scale / fiopsd->read_scale;
+ if (!rq_is_sync(rq))
+ vios = vios * fiopsd->async_scale / fiopsd->sync_scale;
+
return vios;
}
@@ -513,6 +520,8 @@ static void *fiops_init_queue(struct req
fiopsd->read_scale = VIOS_READ_SCALE;
fiopsd->write_scale = VIOS_WRITE_SCALE;
+ fiopsd->sync_scale = VIOS_SYNC_SCALE;
+ fiopsd->async_scale = VIOS_ASYNC_SCALE;
return fiopsd;
}
@@ -557,6 +566,8 @@ static ssize_t __FUNC(struct elevator_qu
}
SHOW_FUNCTION(fiops_read_scale_show, fiopsd->read_scale);
SHOW_FUNCTION(fiops_write_scale_show, fiopsd->write_scale);
+SHOW_FUNCTION(fiops_sync_scale_show, fiopsd->sync_scale);
+SHOW_FUNCTION(fiops_async_scale_show, fiopsd->async_scale);
#undef SHOW_FUNCTION
#define STORE_FUNCTION(__FUNC, __PTR, MIN, MAX) \
@@ -574,6 +585,8 @@ static ssize_t __FUNC(struct elevator_qu
}
STORE_FUNCTION(fiops_read_scale_store, &fiopsd->read_scale, 1, 100);
STORE_FUNCTION(fiops_write_scale_store, &fiopsd->write_scale, 1, 100);
+STORE_FUNCTION(fiops_sync_scale_store, &fiopsd->sync_scale, 1, 100);
+STORE_FUNCTION(fiops_async_scale_store, &fiopsd->async_scale, 1, 100);
#undef STORE_FUNCTION
#define FIOPS_ATTR(name) \
@@ -582,6 +595,8 @@ STORE_FUNCTION(fiops_write_scale_store,
static struct elv_fs_entry fiops_attrs[] = {
FIOPS_ATTR(read_scale),
FIOPS_ATTR(write_scale),
+ FIOPS_ATTR(sync_scale),
+ FIOPS_ATTR(async_scale),
__ATTR_NULL
};
next prev parent reply other threads:[~2012-01-30 7:07 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 ` Shaohua Li [this message]
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 ` [patch v2 0/8]block: An IOPS based ioscheduler Shaohua Li
2012-01-30 15:30 ` 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=20120130070634.587891025@sli10-conroe.sh.intel.com \
--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).