From: Dave Hansen <dave@linux.vnet.ibm.com>
To: righi.andrea@gmail.com
Cc: xen-devel@lists.xensource.com,
containers@lists.linux-foundation.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, dm-devel@redhat.com,
agk@sourceware.org
Subject: Re: Too many I/O controller patches
Date: Mon, 04 Aug 2008 12:02:01 -0700 [thread overview]
Message-ID: <1217876521.20260.123.camel@nimitz> (raw)
In-Reply-To: <489748E6.5080106@gmail.com>
On Mon, 2008-08-04 at 20:22 +0200, Andrea Righi wrote:
> But I'm not yet convinced that limiting the IO writes at the device
> mapper layer is the best solution. IMHO it would be better to throttle
> applications' writes when they're dirtying pages in the page cache (the
> io-throttle way), because when the IO requests arrive to the device
> mapper it's too late (we would only have a lot of dirty pages that are
> waiting to be flushed to the limited block devices, and maybe this could
> lead to OOM conditions). IOW dm-ioband is doing this at the wrong level
> (at least for my requirements). Ryo, correct me if I'm wrong or if I've
> not understood the dm-ioband approach.
The avoid-lots-of-page-dirtying problem sounds like a hard one. But, if
you look at this in combination with the memory controller, they would
make a great team.
The memory controller keeps you from dirtying more than your limit of
pages (and pinning too much memory) even if the dm layer is doing the
throttling and itself can't throttle the memory usage.
I also don't think this is any different from the problems we have in
the regular VM these days. Right now, people can dirty lots of pages on
devices that are slow. The only thing dm-ioband would be added would be
changing how those devices *got* slow. :)
-- Dave
next prev parent reply other threads:[~2008-08-04 19:02 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-04 8:51 [PATCH 0/7] I/O bandwidth controller and BIO tracking Ryo Tsuruta
2008-08-04 8:52 ` [PATCH 1/7] dm-ioband: Patch of device-mapper driver Ryo Tsuruta
2008-08-04 8:52 ` [PATCH 2/7] dm-ioband: Documentation of design overview, installation, command reference and examples Ryo Tsuruta
2008-08-04 8:57 ` [PATCH 3/7] bio-cgroup: Introduction Ryo Tsuruta
2008-08-04 8:57 ` [PATCH 4/7] bio-cgroup: Split the cgroup memory subsystem into two parts Ryo Tsuruta
2008-08-04 8:59 ` [PATCH 5/7] bio-cgroup: Remove a lot of ifdefs Ryo Tsuruta
2008-08-04 9:00 ` [PATCH 6/7] bio-cgroup: Implement the bio-cgroup Ryo Tsuruta
2008-08-04 9:01 ` [PATCH 7/7] bio-cgroup: Add a cgroup support to dm-ioband Ryo Tsuruta
2008-08-08 7:10 ` [PATCH 6/7] bio-cgroup: Implement the bio-cgroup Takuya Yoshikawa
2008-08-08 8:30 ` Ryo Tsuruta
2008-08-08 9:42 ` Takuya Yoshikawa
2008-08-08 11:41 ` Ryo Tsuruta
2008-08-05 10:25 ` [PATCH 4/7] bio-cgroup: Split the cgroup memory subsystem into two parts Andrea Righi
2008-08-05 10:35 ` Hirokazu Takahashi
2008-08-06 7:54 ` KAMEZAWA Hiroyuki
2008-08-06 11:43 ` Hirokazu Takahashi
2008-08-06 13:45 ` kamezawa.hiroyu
2008-08-07 7:25 ` Hirokazu Takahashi
2008-08-07 8:21 ` KAMEZAWA Hiroyuki
2008-08-07 8:45 ` Hirokazu Takahashi
2008-08-04 17:20 ` Too many I/O controller patches Dave Hansen
2008-08-04 18:22 ` Andrea Righi
2008-08-04 19:02 ` Dave Hansen [this message]
2008-08-04 20:44 ` Andrea Righi
2008-08-04 20:50 ` Dave Hansen
2008-08-05 6:28 ` Hirokazu Takahashi
2008-08-05 5:55 ` Paul Menage
2008-08-05 6:03 ` Balbir Singh
2008-08-05 9:27 ` Andrea Righi
2008-08-05 16:25 ` Dave Hansen
2008-08-05 6:16 ` Hirokazu Takahashi
2008-08-05 9:31 ` Andrea Righi
2008-08-05 10:01 ` Hirokazu Takahashi
2008-08-05 2:50 ` Satoshi UCHIDA
2008-08-05 9:28 ` Andrea Righi
2008-08-05 13:17 ` Ryo Tsuruta
2008-08-05 16:20 ` Dave Hansen
2008-08-06 2:44 ` KAMEZAWA Hiroyuki
2008-08-06 3:30 ` Balbir Singh
2008-08-06 6:48 ` Hirokazu Takahashi
2008-08-05 12:01 ` Hirokazu Takahashi
2008-08-04 18:34 ` Balbir Singh
2008-08-04 20:42 ` Andrea Righi
2008-08-06 1:13 ` RFC: I/O bandwidth controller (was Re: Too many I/O controller patches) Fernando Luis Vázquez Cao
2008-08-06 6:18 ` RFC: I/O bandwidth controller Ryo Tsuruta
2008-08-06 6:41 ` Fernando Luis Vázquez Cao
2008-08-06 15:48 ` Dave Hansen
2008-08-07 4:38 ` Fernando Luis Vázquez Cao
2008-08-06 16:42 ` RFC: I/O bandwidth controller (was Re: Too many I/O controller patches) Balbir Singh
2008-08-06 18:00 ` Dave Hansen
2008-08-07 2:44 ` Fernando Luis Vázquez Cao
2008-08-07 3:01 ` Fernando Luis Vázquez Cao
2008-08-08 11:39 ` RFC: I/O bandwidth controller Hirokazu Takahashi
2008-08-12 5:35 ` Fernando Luis Vázquez Cao
2008-08-06 19:37 ` RFC: I/O bandwidth controller (was Re: Too many I/O controller patches) Naveen Gupta
2008-08-07 8:30 ` RFC: I/O bandwidth controller Hirokazu Takahashi
2008-08-07 13:17 ` RFC: I/O bandwidth controller (was Re: Too many I/O controller patches) Fernando Luis Vázquez Cao
2008-08-11 18:18 ` Naveen Gupta
2008-08-11 16:35 ` David Collier-Brown
2008-08-07 7:46 ` Andrea Righi
2008-08-07 13:59 ` Fernando Luis Vázquez Cao
2008-08-11 20:52 ` Andrea Righi
[not found] ` <loom.20080812T071504-212@post.gmane.org>
2008-08-12 11:10 ` RFC: I/O bandwidth controller Hirokazu Takahashi
2008-08-12 12:55 ` Andrea Righi
2008-08-12 13:07 ` Andrea Righi
2008-08-12 13:54 ` Fernando Luis Vázquez Cao
2008-08-12 15:03 ` James.Smart
2008-08-12 21:00 ` Andrea Righi
2008-08-12 20:44 ` Andrea Righi
2008-08-13 7:47 ` Dong-Jae Kang
2008-08-13 17:56 ` Andrea Righi
2008-08-14 11:18 ` David Collier-Brown
2008-08-12 13:15 ` Fernando Luis Vázquez Cao
2008-08-13 6:23 ` 강동재
2008-08-08 6:21 ` Hirokazu Takahashi
2008-08-08 7:20 ` Ryo Tsuruta
2008-08-08 8:10 ` Fernando Luis Vázquez Cao
2008-08-08 10:05 ` Ryo Tsuruta
2008-08-08 14:31 ` Hirokazu Takahashi
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=1217876521.20260.123.camel@nimitz \
--to=dave@linux.vnet.ibm.com \
--cc=agk@sourceware.org \
--cc=containers@lists.linux-foundation.org \
--cc=dm-devel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=righi.andrea@gmail.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=xen-devel@lists.xensource.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