From: Andrea Righi <righi.andrea@gmail.com>
To: Munehiro Ikeda <m-ikeda@ds.jp.nec.com>
Cc: linux-kernel@vger.kernel.org, jens.axboe@oracle.com,
Vivek Goyal <vgoyal@redhat.com>, Ryo Tsuruta <ryov@valinux.co.jp>,
taka@valinux.co.jp, kamezawa.hiroyu@jp.fujitsu.com,
Gui Jianfeng <guijianfeng@cn.fujitsu.com>,
akpm@linux-foundation.org, balbir@linux.vnet.ibm.com,
Greg Thelen <gthelen@google.com>
Subject: Re: [RFC][PATCH 00/11] blkiocg async support
Date: Fri, 9 Jul 2010 12:04:22 +0200 [thread overview]
Message-ID: <20100709100422.GB1814@linux.develer.com> (raw)
In-Reply-To: <4C369009.80503@ds.jp.nec.com>
On Thu, Jul 08, 2010 at 10:57:13PM -0400, Munehiro Ikeda wrote:
> This might be a piece of puzzle for complete async write support of blkio
> controller. One of other pieces in my head is page dirtying ratio control.
> I believe Andrea Righi was working on it...how about the situation?
Greg Thelen (cc'ed) did some progresses on my original work. AFAIK
there're still some locking issue to resolve, principally because
cgroup dirty memory accounting requires lock_page_cgroup() to be
irq-safe. I did some tests using the irq-safe locking vs trylock
approach and Greg also tested the RCU way.
The RCU approach seems promising IMHO, because the page's cgroup owner
is supposed to change rarely (except for the files shared and frequently
written by many cgroups).
Greg, do you have a patch rebased to a recent kernel?
Thanks,
-Andrea
next prev parent reply other threads:[~2010-07-09 10:04 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-09 2:57 [RFC][PATCH 00/11] blkiocg async support Munehiro Ikeda
2010-07-09 3:14 ` [RFC][PATCH 01/11] blkiocg async: Make page_cgroup independent from memory controller Munehiro Ikeda
2010-07-26 6:49 ` Balbir Singh
2010-07-09 3:15 ` [RFC][PATCH 02/11] blkiocg async: The main part of iotrack Munehiro Ikeda
2010-07-09 7:35 ` KAMEZAWA Hiroyuki
2010-07-09 23:06 ` Munehiro Ikeda
2010-07-12 0:11 ` KAMEZAWA Hiroyuki
2010-07-14 14:46 ` Munehiro IKEDA
2010-07-09 7:38 ` KAMEZAWA Hiroyuki
2010-07-09 23:09 ` Munehiro Ikeda
2010-07-10 10:06 ` Andrea Righi
2010-07-09 3:16 ` [RFC][PATCH 03/11] blkiocg async: Hooks for iotrack Munehiro Ikeda
2010-07-09 9:24 ` Andrea Righi
2010-07-09 23:43 ` Munehiro Ikeda
2010-07-09 3:16 ` [RFC][PATCH 04/11] blkiocg async: block_commit_write not to record process info Munehiro Ikeda
2010-07-09 3:17 ` [RFC][PATCH 05/11] blkiocg async: __set_page_dirty_nobuffer " Munehiro Ikeda
2010-07-09 3:17 ` [RFC][PATCH 06/11] blkiocg async: ext4_writepage not to overwrite iotrack info Munehiro Ikeda
2010-07-09 3:18 ` [RFC][PATCH 07/11] blkiocg async: Pass bio to elevator_ops functions Munehiro Ikeda
2010-07-09 3:19 ` [RFC][PATCH 08/11] blkiocg async: Function to search blkcg from css ID Munehiro Ikeda
2010-07-09 3:20 ` [RFC][PATCH 09/11] blkiocg async: Functions to get cfqg from bio Munehiro Ikeda
2010-07-09 3:22 ` [RFC][PATCH 10/11] blkiocg async: Async queue per cfq_group Munehiro Ikeda
2010-08-13 1:24 ` Nauman Rafique
2010-08-13 21:00 ` Munehiro Ikeda
2010-08-13 23:01 ` Nauman Rafique
2010-08-14 0:49 ` Munehiro Ikeda
2010-07-09 3:23 ` [RFC][PATCH 11/11] blkiocg async: Workload timeslice adjustment for async queues Munehiro Ikeda
2010-07-09 10:04 ` Andrea Righi [this message]
2010-07-09 13:45 ` [RFC][PATCH 00/11] blkiocg async support Vivek Goyal
2010-07-10 0:17 ` Munehiro Ikeda
2010-07-10 0:55 ` Nauman Rafique
2010-07-10 13:24 ` Vivek Goyal
2010-07-12 0:20 ` KAMEZAWA Hiroyuki
2010-07-12 13:18 ` Vivek Goyal
2010-07-13 4:36 ` KAMEZAWA Hiroyuki
2010-07-14 14:29 ` Vivek Goyal
2010-07-15 0:00 ` KAMEZAWA Hiroyuki
2010-07-16 13:43 ` Vivek Goyal
2010-07-16 14:15 ` Daniel P. Berrange
2010-07-16 14:35 ` Vivek Goyal
2010-07-16 14:53 ` Daniel P. Berrange
2010-07-16 15:12 ` Vivek Goyal
2010-07-27 10:40 ` Daniel P. Berrange
2010-07-27 14:03 ` Vivek Goyal
2010-07-22 19:28 ` Greg Thelen
2010-07-22 23:59 ` KAMEZAWA Hiroyuki
2010-07-26 6:41 ` Balbir Singh
2010-07-27 6:40 ` Greg Thelen
2010-07-27 6:39 ` KAMEZAWA Hiroyuki
2010-08-02 20:58 ` Vivek Goyal
2010-08-03 14:31 ` Munehiro Ikeda
2010-08-03 19:24 ` Nauman Rafique
2010-08-04 14:32 ` Munehiro Ikeda
2010-08-03 20:15 ` Vivek Goyal
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=20100709100422.GB1814@linux.develer.com \
--to=righi.andrea@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=gthelen@google.com \
--cc=guijianfeng@cn.fujitsu.com \
--cc=jens.axboe@oracle.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m-ikeda@ds.jp.nec.com \
--cc=ryov@valinux.co.jp \
--cc=taka@valinux.co.jp \
--cc=vgoyal@redhat.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