[Devel] Re: [PATCH 9/9] ext3: do not throttle metadata and journal IO
Andrea Righi
righi.andrea at gmail.com
Tue Apr 21 07:31:31 PDT 2009
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
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list