All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Ryo Tsuruta <ryov@valinux.co.jp>
Cc: guijianfeng@cn.fujitsu.com, linux-kernel@vger.kernel.org,
	jmoyer@redhat.com, dm-devel@redhat.com, vgoyal@redhat.com,
	jens.axboe@oracle.com, nauman@google.com,
	akpm@linux-foundation.org, agk@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.

WARNING: multiple messages have this Message-ID (diff)
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.

  parent reply	other threads:[~2009-09-08 19:24 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-01 16:50 Regarding dm-ioband tests Vivek Goyal
2009-09-01 16:50 ` Vivek Goyal
2009-09-01 17:47 ` Vivek Goyal
2009-09-01 17:47   ` Vivek Goyal
2009-09-03 13:11   ` 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-15 21:40         ` Vivek Goyal
2009-09-16 11:10         ` dm-ioband fairness in terms of sectors seems to be killing disk Ryo Tsuruta
2009-09-16 11:10           ` Ryo Tsuruta
2009-09-04  4:02 ` Regarding dm-ioband tests Ryo Tsuruta
2009-09-04  4:02   ` Ryo Tsuruta
2009-09-04 23:11   ` Vivek Goyal
2009-09-04 23:11     ` Vivek Goyal
2009-09-07 11:02     ` Ryo Tsuruta
2009-09-07 11:02       ` Ryo Tsuruta
2009-09-07 13:53       ` Rik van Riel
2009-09-07 13:53         ` Rik van Riel
2009-09-08  3:01         ` Ryo Tsuruta
2009-09-08  3:01           ` Ryo Tsuruta
2009-09-08  3:22           ` Balbir Singh
2009-09-08  3:22             ` Balbir Singh
2009-09-08  5:05             ` Ryo Tsuruta
2009-09-08  5:05               ` Ryo Tsuruta
2009-09-08 13:49               ` Vivek Goyal
2009-09-08 13:49                 ` Vivek Goyal
2009-09-09  5:17                 ` Ryo Tsuruta
2009-09-09  5:17                   ` Ryo Tsuruta
2009-09-09 13:34                   ` Vivek Goyal
2009-09-09 13:34                     ` Vivek Goyal
2009-09-08 13:42           ` Vivek Goyal
2009-09-08 13:42             ` Vivek Goyal
2009-09-08 16:30             ` Nauman Rafique
2009-09-08 16:30               ` Nauman Rafique
2009-09-08 16:47               ` Rik van Riel
2009-09-08 16:47                 ` Rik van Riel
2009-09-08 17:54                 ` Vivek Goyal
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-15 23:37                     ` 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  6:05                 ` Ryo Tsuruta
2009-09-09 10:51                 ` Dhaval Giani
2009-09-10  7:58                   ` Ryo Tsuruta
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:12                         ` Ryo Tsuruta
2009-09-15 15:19                         ` Balbir Singh
2009-09-15 15:19                           ` Balbir Singh
2009-09-15 15:58                           ` Rik van Riel
2009-09-15 15:58                             ` Rik van Riel
2009-09-15 16:21                           ` Ryo Tsuruta
2009-09-15 16:21                             ` Ryo Tsuruta
2009-09-09 13:57                 ` Vivek Goyal
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-09 14:31                 ` Vivek Goyal
2009-09-10  3:45                 ` Ryo Tsuruta
2009-09-10 13:25                   ` Vivek Goyal
2009-09-10 13:25                     ` Vivek Goyal
2009-09-08 19:24           ` Rik van Riel [this message]
2009-09-08 19:24             ` Rik van Riel
2009-09-09  0:09             ` Fabio Checconi
2009-09-09  2:06               ` Vivek Goyal
2009-09-09  2:06                 ` Vivek Goyal
2009-09-09 15:41                 ` Fabio Checconi
2009-09-09 17:30                   ` Vivek Goyal
2009-09-09 17:30                     ` Vivek Goyal
2009-09-09 19:01                     ` Fabio Checconi
2009-09-09  9:24               ` Ryo Tsuruta
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-16  4:45         ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.