[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48976A2A.9060600@gmail.com>
Date: Mon, 04 Aug 2008 22:44:26 +0200
From: Andrea Righi <righi.andrea@...il.com>
To: Dave Hansen <dave@...ux.vnet.ibm.com>
CC: xen-devel@...ts.xensource.com,
containers@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org,
virtualization@...ts.linux-foundation.org, dm-devel@...hat.com,
agk@...rceware.org
Subject: Re: Too many I/O controller patches
Dave Hansen wrote:
> 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.
mmh... but in this way we would just move the OOM inside the cgroup,
that is a nice improvement, but the main problem is not resolved...
A safer approach IMHO is to force the tasks to wait synchronously on
each operation that directly or indirectly generates i/o.
In particular the solution used by the io-throttle controller to limit
the dirty-ratio in memory is to impose a sleep via
schedule_timeout_killable() in balance_dirty_pages() when a generic
process exceeds the limits defined for the belonging cgroup.
Limiting read operations is a lot more easy, because they're always
synchronized with i/o requests.
-Andrea
--
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