From: Rik van Riel <riel@redhat.com>
To: Ryo Tsuruta <ryov@valinux.co.jp>
Cc: vgoyal@redhat.com, linux-kernel@vger.kernel.org,
dm-devel@redhat.com, jens.axboe@oracle.com, agk@redhat.com,
akpm@linux-foundation.org, nauman@google.com,
guijianfeng@cn.fujitsu.com, jmoyer@redhat.com,
balbir@linux.vnet.ibm.com
Subject: Re: Regarding dm-ioband tests
Date: Tue, 08 Sep 2009 15:24:08 -0400 [thread overview]
Message-ID: <4AA6AF58.3050501@redhat.com> (raw)
In-Reply-To: <20090908.120119.71095369.ryov@valinux.co.jp>
Ryo Tsuruta wrote:
> Rik van Riel <riel@redhat.com> wrote:
>> Are you saying that dm-ioband is purposely unfair,
>> until a certain load level is reached?
>
> Not unfair, dm-ioband(weight policy) is intentionally designed to
> use bandwidth efficiently, weight policy tries to give spare bandwidth
> of inactive groups to active groups.
This sounds good, except that the lack of anticipation
means that a group with just one task doing reads will
be considered "inactive" in-between reads.
This means writes can always get in-between two reads,
sometimes multiple writes at a time, really disadvantaging
a group that is doing just disk reads.
This is a problem, because reads are generally more time
sensitive than writes.
>>> We regarded reducing throughput loss rather than reducing duration
>>> as the design of dm-ioband. Of course, it is possible to make a new
>>> policy which reduces duration.
>> ... while also reducing overall system throughput
>> by design?
>
> I think it reduces system throughput compared to the current
> implementation, because it causes more overhead to do fine grained
> control.
Except that the io scheduler based io controller seems
to be able to enforce fairness while not reducing
throughput.
Dm-ioband would have to address these issues to be a
serious contender, IMHO.
--
All rights reversed.
next prev parent reply other threads:[~2009-09-08 19:24 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-01 16:50 Regarding dm-ioband tests Vivek Goyal
2009-09-01 17:47 ` Vivek Goyal
2009-09-03 13:11 ` Vivek Goyal
2009-09-04 1:12 ` Ryo Tsuruta
2009-09-15 21:40 ` dm-ioband fairness in terms of sectors seems to be killing disk (Was: Re: Regarding dm-ioband tests) Vivek Goyal
2009-09-16 11:10 ` dm-ioband fairness in terms of sectors seems to be killing disk Ryo Tsuruta
2009-09-04 4:02 ` Regarding dm-ioband tests Ryo Tsuruta
2009-09-04 23:11 ` Vivek Goyal
2009-09-07 11:02 ` Ryo Tsuruta
2009-09-07 13:53 ` Rik van Riel
2009-09-08 3:01 ` Ryo Tsuruta
2009-09-08 3:22 ` Balbir Singh
2009-09-08 5:05 ` Ryo Tsuruta
2009-09-08 13:49 ` Vivek Goyal
2009-09-09 5:17 ` Ryo Tsuruta
2009-09-09 13:34 ` Vivek Goyal
2009-09-08 13:42 ` Vivek Goyal
2009-09-08 16:30 ` Nauman Rafique
2009-09-08 16:47 ` Rik van Riel
2009-09-08 17:54 ` Vivek Goyal
2009-09-15 23:37 ` ioband: Writer starves reader even without competitors (Re: Regarding dm-ioband tests) Vivek Goyal
2009-09-16 12:08 ` ioband: Writer starves reader even without competitors Ryo Tsuruta
2009-09-08 17:06 ` Regarding dm-ioband tests Dhaval Giani
2009-09-09 6:05 ` Ryo Tsuruta
2009-09-09 10:51 ` Dhaval Giani
2009-09-10 7:58 ` Ryo Tsuruta
2009-09-11 9:53 ` Dhaval Giani
2009-09-15 15:12 ` Ryo Tsuruta
2009-09-15 15:19 ` Balbir Singh
2009-09-15 15:58 ` Rik van Riel
2009-09-15 16:21 ` Ryo Tsuruta
2009-09-09 13:57 ` Vivek Goyal
2009-09-10 3:06 ` Ryo Tsuruta
2009-09-09 10:01 ` Ryo Tsuruta
2009-09-09 14:31 ` Vivek Goyal
2009-09-10 3:45 ` Ryo Tsuruta
2009-09-10 13:25 ` Vivek Goyal
2009-09-08 19:24 ` Rik van Riel [this message]
2009-09-09 0:09 ` Fabio Checconi
2009-09-09 2:06 ` Vivek Goyal
2009-09-09 15:41 ` Fabio Checconi
2009-09-09 17:30 ` Vivek Goyal
2009-09-09 19:01 ` Fabio Checconi
2009-09-09 9:24 ` Ryo Tsuruta
2009-09-16 4:45 ` ioband: Limited fairness and weak isolation between groups (Was: Re: Regarding dm-ioband tests) Vivek Goyal
2009-09-18 7:33 ` ioband: Limited fairness and weak isolation between groups Ryo Tsuruta
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=4AA6AF58.3050501@redhat.com \
--to=riel@redhat.com \
--cc=agk@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=dm-devel@redhat.com \
--cc=guijianfeng@cn.fujitsu.com \
--cc=jens.axboe@oracle.com \
--cc=jmoyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nauman@google.com \
--cc=ryov@valinux.co.jp \
--cc=vgoyal@redhat.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).