From: Andrea Righi <righi.andrea@gmail.com>
To: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>,
Paul Menage <menage@google.com>,
agk@sourceware.org, akpm@linux-foundation.org, axboe@kernel.dk,
baramsori72@gmail.com, Carl Henrik Lunde <chlunde@ping.uio.no>,
dave@linux.vnet.ibm.com, Divyesh Shah <dpshah@google.com>,
eric.rannaud@gmail.com, fernando@oss.ntt.co.jp,
Hirokazu Takahashi <taka@valinux.co.jp>,
Li Zefan <lizf@cn.fujitsu.com>,
Marco Innocenti <m.innocenti@cineca.it>,
matt@bluehost.com, ngupta@google.com, randy.dunlap@oracle.com,
roberto@unbit.it, Ryo Tsuruta <ryov@valinux.co.jp>,
Satoshi UCHIDA <s-uchida@ap.jp.nec.com>,
subrata@linux.vnet.ibm.com,
containers@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH -mm 0/5] cgroup: block device i/o controller (v9)
Date: Wed, 17 Sep 2008 12:08:29 +0200 [thread overview]
Message-ID: <48D0D71D.2040100@gmail.com> (raw)
In-Reply-To: <48D0C800.30207@oss.ntt.co.jp>
Takuya Yoshikawa wrote:
> Hi,
>
> Andrea Righi wrote:
>> TODO:
>>
>> * Try to push down the throttling and implement it directly in the I/O
>> schedulers, using bio-cgroup (http://people.valinux.co.jp/~ryov/bio-cgroup/)
>> to keep track of the right cgroup context. This approach could lead to more
>> memory consumption and increases the number of dirty pages (hard/slow to
>> reclaim pages) in the system, since dirty-page ratio in memory is not
>> limited. This could even lead to potential OOM conditions, but these problems
>> can be resolved directly into the memory cgroup subsystem
>>
>> * Handle I/O generated by kswapd: at the moment there's no control on the I/O
>> generated by kswapd; try to use the page_cgroup functionality of the memory
>> cgroup controller to track this kind of I/O and charge the right cgroup when
>> pages are swapped in/out
>
> Could you explain which cgroup we should charge when swap in or out occurs?
> Are there any difference between the following cases?
>
> Target page is
> 1. used as page cache and not mapped to any space
> 2. used as page cache and mapped to some space
> 3. not used as page cache and mapped to some space
>
> I do not think it is fair to charge the process for this kind of I/O, am I wrong?
As a generic implementation, when a read/write request is submitted to the
IO subsystem (i.e. submit_bio()), look at the first page in the struct bio
and charge the IO cost to the owner of that page. It this makes sense, we
have to just keep track of all the pages when they're submitted to the IO
subsystem in this way. Unfortunately, this doesn't seem to work during
swap_writepage(), but maybe bio-cgroup is able to handle this case.
-Andrea
prev parent reply other threads:[~2008-09-17 10:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-27 16:07 [RFC][PATCH -mm 0/5] cgroup: block device i/o controller (v9) Andrea Righi
2008-09-02 18:06 ` Vivek Goyal
2008-09-02 20:50 ` Andrea Righi
2008-09-02 21:41 ` Vivek Goyal
2008-09-05 15:59 ` Vivek Goyal
2008-09-05 17:38 ` Andrea Righi
2008-09-17 7:18 ` Hirokazu Takahashi
2008-09-17 8:47 ` Andrea Righi
2008-09-18 11:24 ` Hirokazu Takahashi
2008-09-18 14:37 ` Andrea Righi
2008-09-18 13:55 ` Vivek Goyal
2008-09-18 14:54 ` Andrea Righi
2008-09-17 9:04 ` Takuya Yoshikawa
2008-09-17 9:42 ` Andrea Righi
2008-09-17 10:08 ` Andrea Righi [this message]
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=48D0D71D.2040100@gmail.com \
--to=righi.andrea@gmail.com \
--cc=agk@sourceware.org \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=balbir@linux.vnet.ibm.com \
--cc=baramsori72@gmail.com \
--cc=chlunde@ping.uio.no \
--cc=containers@lists.linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=dpshah@google.com \
--cc=eric.rannaud@gmail.com \
--cc=fernando@oss.ntt.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=m.innocenti@cineca.it \
--cc=matt@bluehost.com \
--cc=menage@google.com \
--cc=ngupta@google.com \
--cc=randy.dunlap@oracle.com \
--cc=roberto@unbit.it \
--cc=ryov@valinux.co.jp \
--cc=s-uchida@ap.jp.nec.com \
--cc=subrata@linux.vnet.ibm.com \
--cc=taka@valinux.co.jp \
--cc=yoshikawa.takuya@oss.ntt.co.jp \
/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