Messages in this thread | | | Date | Tue, 21 Apr 2009 16:31:31 +0200 | From | Andrea Righi <> | Subject | Re: [PATCH 9/9] ext3: do not throttle metadata and journal IO |
| |
On Tue, Apr 21, 2009 at 10:06:31AM -0400, Theodore Tso wrote: > On Tue, Apr 21, 2009 at 10:30:02AM +0200, Andrea Righi wrote: > > > > We're trying to address also this issue, setting max dirty pages limit > > per cgroup, and force a direct writeback when these limits are exceeded. > > > > In this case dirty ratio throttling should happen automatically because > > the process will be throttled by the IO controller when it tries to > > writeback the dirty pages and submit IO requests. > > The challenge here will be the accounting; consider that you may have > a file that had some of its pages in its page cache dirtied by a > process in cgroup A. Now another process in cgroup B dirties some > more pages. This could happen either via a mmap'ed file or via the > standard read/write system calls. How do you track which dirty pages > should be charged against which cgroup? > > - Ted
Some months ago I posted a proposal to account, track and limit per cgroup dirty pages in the memory cgroup subsystem:
https://lists.linux-foundation.org/pipermail/containers/2008-September/013140.html
At the moment I'm reworking on a similar and updated version. I know that Kamezawa is also implementing something to account per cgroup dirty pages in memory cgroup.
Moreover, io-throttle v14 already uses the page_cgroup structure to encode into page_cgroup->flags the cgroup ID (io-throttle css_id() actually) that originally dirtied the page.
This should be enough to track dirty pages and charge the right cgroup.
-Andrea
| |