[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080805.221717.112609710.ryov@valinux.co.jp>
Date: Tue, 05 Aug 2008 22:17:17 +0900 (JST)
From: Ryo Tsuruta <ryov@...inux.co.jp>
To: righi.andrea@...il.com
Cc: s-uchida@...jp.nec.com, ngupta@...gle.com, vtaras@...nvz.org,
dave@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
dm-devel@...hat.com, containers@...ts.linux-foundation.org,
virtualization@...ts.linux-foundation.org,
xen-devel@...ts.xensource.com, agk@...rceware.org
Subject: Re: Too many I/O controller patches
Hi Andrea, Satoshi and all,
Thanks for giving a chance to discuss.
> Mr. Andrew gave a advice "Should discuss about design more and more"
> to me.
> And, in Containers Mini-summit (and Linux Symposium 2008 in Ottawa),
> Paul said that a necessary to us is to decide a requirement first.
> So, we must discuss requirement and design.
We've implemented dm-ioband and bio-cgroup to meet the following requirements:
* Assign some bandwidth to each group on the same device.
A group is a set of processes, which may be a cgroup.
* Assign some bandwidth to each partition on the same device.
It can work with the process group based bandwidth control.
ex) With this feature, you can assign 40% of the bandwidth of a
disk to /root and 60% of them to /usr.
* It can work with virtual machines such as Xen and KVM.
I/O requests issued from virtual machines have to be controlled.
* It should work any type of I/O scheduler, including ones which
will be released in the future.
* Support multiple devices which share the same bandwidth such as
raid disks and LVM.
* Handle asynchronous I/O requests such as AIO request and delayed
write requests.
- This can be done with bio-cgroup, which uses the page-tracking
mechanism the cgroup memory controller has.
* Control dirty page ratio.
- This can be done with the cgroup memory controller in the near
feature. It would be great that you can also use other features
the memory controller is going to have with dm-ioband.
* Make it easy to enhance.
- The current implementation of dm-ioband has an interface to
add a new policy to control I/O requests. You can easily add
I/O throttling policy if you want.
* Fine grained bandwidth control.
* Keep I/O throughput.
* Make it scalable.
* It should work correctly if the I/O load is quite high,
even when the io-request queue of a certain disk is overflowed.
> Ryo, do you have other documentation besides the info reported in the
> dm-ioband website?
I don't have any documentation besides in the website.
Thanks,
Ryo Tsuruta
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists