[Devel] Re: [PATCH 0/2] dm-ioband: I/O bandwidth controller v1.8.0: Introduction

2008-10-20 Thread KAMEZAWA Hiroyuki
On Mon, 20 Oct 2008 21:48:58 +0900 (JST) Ryo Tsuruta <[EMAIL PROTECTED]> wrote: > Hi Dong-Jae, > > > Well, do you have any plan to upgrade bio-cgroup patches for stable > > latest kernel? > > but, I think it will be not easy job ^^ > > I think the memory cgroup will have a major change sometime

[Devel] Re: About bio-cgroup

2008-10-29 Thread KAMEZAWA Hiroyuki
On Wed, 29 Oct 2008 17:07:18 +0900 (JST) Hirokazu Takahashi <[EMAIL PROTECTED]> wrote: > Hi, > > > Hi Ryo, > > > > The page_cgroup seems to be stable in the latest kernel. > > I'd like to know whether you have a plan or schedule to release > > a new version of bio-cgroup against latest kernel. >

[Devel] Re: About bio-cgroup

2008-10-29 Thread KAMEZAWA Hiroyuki
On Wed, 29 Oct 2008 14:32:29 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > KAMEZAWA Hiroyuki wrote: > > On Wed, 29 Oct 2008 17:07:18 +0900 (JST) > > Hirokazu Takahashi <[EMAIL PROTECTED]> wrote: > > > >> Hi, > >> > >>> Hi Ryo, >

[Devel] Re: [patch 0/7] cpuset writeback throttling

2008-11-04 Thread KAMEZAWA Hiroyuki
On Tue, 4 Nov 2008 15:36:10 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Tue, 4 Nov 2008 16:52:48 -0600 (CST) > Christoph Lameter <[EMAIL PROTECTED]> wrote: > > > On Tue, 4 Nov 2008, Andrew Morton wrote: > > > > > To fix this with a memcg-based throttling, the operator would need to > > >

[Devel] Re: [patch 0/7] cpuset writeback throttling

2008-11-04 Thread KAMEZAWA Hiroyuki
On Tue, 4 Nov 2008 19:05:05 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > Generally, I worry that this is a specific fix to a specific problem > encountered on specific machines with specific setups and specific > workloads, and that it's just all too low-level and myopic. > > And now we're bac

[Devel] Re: [patch 0/7] cpuset writeback throttling

2008-11-05 Thread KAMEZAWA Hiroyuki
On Wed, 5 Nov 2008 14:04:42 -0800 (PST) David Rientjes <[EMAIL PROTECTED]> wrote: > > So the world wouldn't end if we just didn't merge it. Those users > > stick with their workarounds and the kernel remains simpler and > > smaller. > > > > Agreed. This patchset is admittedly from a different

[Devel] Re: [patch 1/4] io controller: documentation

2008-11-06 Thread KAMEZAWA Hiroyuki
On Thu, 06 Nov 2008 10:30:23 -0500 [EMAIL PROTECTED] wrote: > +ISSUES > +== > +- IO controller can buffer the bios if suffcient tokens were not available > + at the time of bio submission. Once the tokens are available, these bios > + are dispatched to elevator/lower layers in first come firs

[Devel] Re: [patch 2/4] io controller: biocgroup implementation

2008-11-06 Thread KAMEZAWA Hiroyuki
On Thu, 06 Nov 2008 10:30:24 -0500 [EMAIL PROTECTED] wrote: > > o biocgroup functionality. > o Implemented new controller "bio" > o Most of it picked from dm-ioband biocgroup implementation patches. > page_cgroup implementation is changed and most of this patch needs rework. please see the lates

[Devel] Re: [patch 3/4] io controller: Core IO controller implementation logic

2008-11-06 Thread KAMEZAWA Hiroyuki
On Thu, 06 Nov 2008 10:30:25 -0500 [EMAIL PROTECTED] wrote: > > o Core IO controller implementation > > Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]> > 2 comments after a quick look. - I don't recommend generic work queue. More stacked dependency between "work" is not good. (I think disk

[Devel] Re: [patch 1/4] io controller: documentation

2008-11-06 Thread KAMEZAWA Hiroyuki
I forget to say that I like your new design in general ;) Thanks, -Kame On Thu, 06 Nov 2008 10:30:23 -0500 [EMAIL PROTECTED] wrote: > > Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]> > > Index: linux17/Documentation/controllers/io-controller.txt > ==

[Devel] Re: [patch 3/4] io controller: Core IO controller implementationlogic

2008-11-07 Thread KAMEZAWA Hiroyuki
Vivek Goyal said: > On Fri, Nov 07, 2008 at 12:21:45PM +0900, KAMEZAWA Hiroyuki wrote: >> On Thu, 06 Nov 2008 10:30:25 -0500 >> [EMAIL PROTECTED] wrote: >> >> > >> > o Core IO controller implementation >> > >> > Signed-off-by: Vivek Goya

[Devel] Re: [PATCH 0/8] I/O bandwidth controller and BIO tracking

2008-11-12 Thread KAMEZAWA Hiroyuki
On Thu, 13 Nov 2008 12:10:19 +0900 (JST) Ryo Tsuruta <[EMAIL PROTECTED]> wrote: > Hi everyone, > > This is a new release of dm-ioband and bio-cgroup. With this release, > the overhead of bio-cgroup is significantly reduced and the accuracy > of block I/O tracking is much improved. These patches a

[Devel] Re: [PATCH] Dynamically allocate struct mem_cgroup_stat_cpu memory

2008-11-13 Thread KAMEZAWA Hiroyuki
On Fri, 14 Nov 2008 11:52:41 +0800 Li Zefan <[EMAIL PROTECTED]> wrote: > CC: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> > CC: Balbir Singh <[EMAIL PROTECTED]> > > Andrew Morton wrote: > > (cc [EMAIL PROTECTED]) > > > > On Thu, 13 Nov 2008 17:

[Devel] [PATCH] memcg: reduce size of per-cpu-stat to be appropriate size.

2008-11-13 Thread KAMEZAWA Hiroyuki
ot based on NR_CPUS but based on nr_cpu_ids. From: Jan Blunck <[EMAIL PROTECTED]> Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> --- mm/memcontrol.c | 34 ++ 1 file changed, 18 insertions(+), 16 deletions(-) Index: mmotm-2.6.2

[Devel] [PATCH] memcg: reduce size of per-cpu-stat to be appropriate size.(v2)

2008-11-13 Thread KAMEZAWA Hiroyuki
u_ids. Changelog: - fixed lack of logic in error path. From: Jan Blunck <[EMAIL PROTECTED]> Reviewed-by: Li Zefan <[EMAIL PROTECTED]> Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> --- mm/memcontrol.c | 35 ++- 1 file changed, 1

[Devel] Re: [PATCH] memcg: reduce size of per-cpu-stat to be appropriate size.

2008-11-13 Thread KAMEZAWA Hiroyuki
On Fri, 14 Nov 2008 13:13:29 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > KAMEZAWA Hiroyuki wrote: > > How about this one ? > > tested on x86-64 + mmotm-Nov10, works well. > > (test on other arch is welcome.) > > > > -Kame > > == > > As Jan

[Devel] Re: [PATCH] memcg: reduce size of per-cpu-stat to be appropriate size.

2008-11-14 Thread KAMEZAWA Hiroyuki
On Fri, 14 Nov 2008 13:33:49 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > Li Zefan wrote: > +static int mem_cgroup_size(void) > >>> inline this function? > >>> > >> necessary ? > >> > > > > Not so necessary IMO. It's called when a cgroup is created and removed, that > > is mkdir and rmdi

[Devel] Re: [PATCH] memcg: fix a typo in Kconfig

2008-11-20 Thread KAMEZAWA Hiroyuki
On Fri, 21 Nov 2008 11:59:20 +0800 Li Zefan <[EMAIL PROTECTED]> wrote: > s/contoller/controller > > Signed-of-by: Li Zefan <[EMAIL PROTECTED]> Thanks, Acked-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> > --- > init/Kconfig |2 +- > 1 files changed, 1 ins

[Devel] Re: [PATCH] memcontrol: rcu_read_lock() to protect mm_match_cgroup()

2008-11-21 Thread KAMEZAWA Hiroyuki
On Fri, 21 Nov 2008 16:49:43 +0800 Lai Jiangshan <[EMAIL PROTECTED]> wrote: > > mm_match_cgroup() calls cgroup_subsys_state(). > > we must use rcu_read_lock() to protect cgroup_subsys_state(). > Thanks, Reviewed-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> > Signed

[Devel] Re: [PATCH] Unused check for thread group leader in mem_cgroup_move_task

2008-11-30 Thread KAMEZAWA Hiroyuki
On Sat, 29 Nov 2008 12:59:27 +0530 Nikanth Karthikesan <[EMAIL PROTECTED]> wrote: > Currently we just check for thread group leader in attach() handler but do > nothing! Either (1) move it to can_attach handler or (2) remove the test > itself. I am attaching patches for both below. > > Thanks

[Devel] Re: [PATCH] Unused check for thread group leader in mem_cgroup_move_task

2008-11-30 Thread KAMEZAWA Hiroyuki
s. Balbir, how do you think ? Reviewed-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> Anyway we have to visit here, again. > Remove the unused test for thread group leader in mem_cgroup_move_task. > > Signed-off-by: Nikanth Karthikesan <[EMAIL PROTECTED]> > > --- > > di

[Devel] Re: [PATCH] Unused check for thread group leader inmem_cgroup_move_task

2008-12-03 Thread KAMEZAWA Hiroyuki
gt; Thanks >> > Nikanth >> > >> Hmm, it seem that code is obsolete. thanks. >> Balbir, how do you think ? >> >> Reviewed-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> >> >> Anyway we have to visit here, again. > > Sorry, I did not

[Devel] Re: [RFC][PATCH 1/3] CGroups: Add a per-subsystem hierarchy_mutex

2008-12-10 Thread KAMEZAWA Hiroyuki
thank you for this work. On Wed, 10 Dec 2008 15:36:55 -0800 [EMAIL PROTECTED] wrote: > This patch adds a hierarchy_mutex to the cgroup_subsys object that > protects changes to the hierarchy observed by that subsystem. It is > taken by the cgroup subsystem (in addition to cgroup_mutex) for the > f

[Devel] Re: [RFC][PATCH 2/3] CGroups: Use hierarchy_mutex in memory controller

2008-12-10 Thread KAMEZAWA Hiroyuki
On Wed, 10 Dec 2008 15:36:56 -0800 [EMAIL PROTECTED] wrote: > This patch updates the memory controller to use its hierarchy_mutex > rather than calling cgroup_lock() to protected against > cgroup_mkdir()/cgroup_rmdir() from occurring in its hierarchy. > > Signed-off-by: Paul Menage <[EMAIL PROTEC

[Devel] Re: [RFC][PATCH 3/3] CGroups: Add css_tryget()

2008-12-10 Thread KAMEZAWA Hiroyuki
On Wed, 10 Dec 2008 15:36:57 -0800 [EMAIL PROTECTED] wrote: > This patch adds css_tryget(), that obtains a counted reference on a > CSS. It is used in situations where the caller has a "weak" reference > to the CSS, i.e. one that does not protect the cgroup from removal via > a reference count, b

[Devel] Re: [RFC][PATCH 2/3] CGroups: Use hierarchy_mutex in memory controller

2008-12-10 Thread KAMEZAWA Hiroyuki
On Wed, 10 Dec 2008 16:52:57 -0800 Paul Menage <[EMAIL PROTECTED]> wrote: > On Wed, Dec 10, 2008 at 4:49 PM, KAMEZAWA Hiroyuki > <[EMAIL PROTECTED]> wrote: > > > >an operation like rmdir() in somewhere. > >hierarchy_lock for A (acquire

[Devel] Re: [RFC][PATCH 3/3] CGroups: Add css_tryget()

2008-12-10 Thread KAMEZAWA Hiroyuki
On Wed, 10 Dec 2008 15:36:57 -0800 [EMAIL PROTECTED] wrote: > This patch adds css_tryget(), that obtains a counted reference on a > CSS. It is used in situations where the caller has a "weak" reference > to the CSS, i.e. one that does not protect the cgroup from removal via > a reference count, b

[Devel] Re: [RFC][PATCH 2/3] CGroups: Use hierarchy_mutex in memory controller

2008-12-10 Thread KAMEZAWA Hiroyuki
On Thu, 11 Dec 2008 12:03:07 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > * KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> [2008-12-11 10:05:01]: > > > On Wed, 10 Dec 2008 16:52:57 -0800 > > Paul Menage <[EMAIL PROTECTED]> wrote: > > > > >

[Devel] [RFC][PATCH]example: use css_tryget() in memcg Re: [RFC][PATCH 3/3] CGroups: Add css_tryget()

2008-12-10 Thread KAMEZAWA Hiroyuki
n know css is alive or not and get refcnt of css in very safe way. ("alive" here means "rmdir/destroy" is not called.) This patch replaces css_get() to css_tryget(), where I cannot explain why css_get() is safe. And removes memcg->obsolete flag. Signed-off-by: KAMEZAWA

[Devel] Re: [RFC][PATCH 3/3] CGroups: Add css_tryget()

2008-12-10 Thread KAMEZAWA Hiroyuki
On Wed, 10 Dec 2008 23:28:12 -0800 Paul Menage <[EMAIL PROTECTED]> wrote: > On Wed, Dec 10, 2008 at 9:15 PM, KAMEZAWA Hiroyuki > <[EMAIL PROTECTED]> wrote: > > > > Could you add this ? > > == > > boolcss_is_removed(struct cgroup_subsys_state *css) &g

[Devel] Re: [RFC][PATCH 2/3] CGroups: Use hierarchy_mutex in memory controller

2008-12-11 Thread KAMEZAWA Hiroyuki
On Thu, 11 Dec 2008 09:05:47 -0800 Paul Menage wrote: > On Wed, Dec 10, 2008 at 10:53 PM, KAMEZAWA Hiroyuki > wrote: > > > > Could you write a document to explain what kind of nest of locks are allowed > > before merging this ? > > We should probably tr

[Devel] Re: Where can I play the memory control (with -mm)

2008-12-17 Thread KAMEZAWA Hiroyuki
On Thu, 18 Dec 2008 11:29:06 +0800 "Ian jonhson" wrote: > Hi Balbin, > > I am very interested in the memory control of container, > but I don't know where I can find the patches to push the > functionalities and how to use the codes via some example > or use cases. > Because it has much relatio

[Devel] Re: [PATCH] cgroups: consolidate cgroup documents

2009-01-08 Thread KAMEZAWA Hiroyuki
gt; Signed-off-by: Li Zefan Oh, I love this patch. Thank you! (about memcg part) Acked-by: KAMEZAWA Hiroyuki > --- > Documentation/cgroups/cgroups.txt|5 +++-- > Documentation/cgroups/memcg_test.txt |2 +- > Documentation/scheduler/sched-design-C

[Devel] Re: [RFC][PATCH] memcg: fix a race when setting memcg.swappiness

2009-01-13 Thread KAMEZAWA Hiroyuki
On Wed, 14 Jan 2009 11:24:18 +0800 Li Zefan wrote: > (suppose: memcg->use_hierarchy == 0 and memcg->swappiness == 60) > > echo 10 > /memcg/0/swappiness | > mem_cgroup_swappiness_write() | > ... | echo 1 > /memcg/0/use_hierarchy > |

[Devel] Re: [RFC][PATCH] memcg: fix a race when setting memcg.swappiness

2009-01-13 Thread KAMEZAWA Hiroyuki
On Wed, 14 Jan 2009 14:47:18 +0800 Li Zefan wrote: > KAMEZAWA Hiroyuki wrote: > > On Wed, 14 Jan 2009 11:24:18 +0800 > > Li Zefan wrote: > > > >> (suppose: memcg->use_hierarchy == 0 and memcg->swappiness == 60) > >> > >> echo 10 > /

[Devel] Re: [RFC][PATCH] memcg: fix a race when setting memcg.swappiness

2009-01-13 Thread KAMEZAWA Hiroyuki
On Wed, 14 Jan 2009 15:22:06 +0800 Li Zefan wrote: > KAMEZAWA Hiroyuki wrote: > > On Wed, 14 Jan 2009 14:47:18 +0800 > > Li Zefan wrote: > > > >> KAMEZAWA Hiroyuki wrote: > >>> On Wed, 14 Jan 2009 11:24:18 +0800 > >>> Li Zefan wrote: >

[Devel] Re: [RFC][PATCH] NOOP cgroup subsystem

2009-01-15 Thread KAMEZAWA Hiroyuki
On Thu, 15 Jan 2009 18:20:45 -0800 Matthew Helsley wrote: > On Fri, 2009-01-09 at 15:32 +0900, KAMEZAWA Hiroyuki wrote: > > On Thu, 8 Jan 2009 22:26:46 -0800 > > Paul Menage wrote: > > > > > On Thu, Jan 8, 2009 at 9:32 PM, KAMEZAWA Hiroyuki > > > wr

[Devel] Re: [RFC][PATCH] NOOP cgroup subsystem

2009-01-15 Thread KAMEZAWA Hiroyuki
On Fri, 16 Jan 2009 11:45:02 +0900 KAMEZAWA Hiroyuki wrote: > On Thu, 15 Jan 2009 18:20:45 -0800 > Matthew Helsley wrote: > I think > - Paul's suggestion sounds attractive. But I can't see fundamental > differences > from user's side between "impl

[Devel] [PATCH] use hierarchy mutex in creation failure path

2009-01-15 Thread KAMEZAWA Hiroyuki
From: KAMEZAWA Hiroyuki Now, cgrp->sibling is handled under hierarchy mutex. error route should do so, too. Signed-off-by: KAMEZAWA Hiroyuki --- kernel/cgroup.c |2 ++ 1 file changed, 2 insertions(+) Index: mmotm-2.6.29-Jan14/kernel/cgrou

[Devel] Re: [PATCH 0/7][v7] Container-init signal semantics

2009-01-18 Thread KAMEZAWA Hiroyuki
On Sat, 17 Jan 2009 12:26:38 -0800 Sukadev Bhattiprolu wrote: > > Container-init must behave like global-init to processes within the > container and hence it must be immune to unhandled fatal signals from > within the container (i.e SIG_DFL signals that terminate the process). > > But the same

[Devel] Re: nsgroup autoremoving

2009-01-18 Thread KAMEZAWA Hiroyuki
On Sun, 18 Jan 2009 17:32:16 -0600 "Serge E. Hallyn" wrote: > Quoting Daniel Lezcano (daniel.lezc...@free.fr): > > Serge E. Hallyn wrote: > >> Quoting Daniel Lezcano (daniel.lezc...@free.fr): > >> > >>> Hi, > >>> > >>> While trying to unshare a namespace with the clone syscall with an > >>>

[Devel] Re: [RFC][PATCH] NOOP cgroup subsystem

2009-01-19 Thread KAMEZAWA Hiroyuki
On Mon, 19 Jan 2009 17:52:36 -0800 Paul Menage wrote: > On Thu, Jan 15, 2009 at 6:20 PM, Matthew Helsley wrote: > > > >My feeling is this should be a signal subsystem rather than a NOOP > > subsystem. Then, if users want the grouping for something besides > > signaling, it doesn't matter

[Devel] Re: [PATCH 0/7][v7] Container-init signal semantics

2009-01-20 Thread KAMEZAWA Hiroyuki
On Tue, 20 Jan 2009 19:05:00 -0800 Sukadev Bhattiprolu wrote: > KAMEZAWA Hiroyuki [kamezawa.hir...@jp.fujitsu.com] wrote: > | On Sat, 17 Jan 2009 12:26:38 -0800 > | Sukadev Bhattiprolu wrote: > | > | > > | > Container-init must behave like global-init to processes wi

[Devel] Re: [PATCH 0/7][v7] Container-init signal semantics

2009-01-20 Thread KAMEZAWA Hiroyuki
On Tue, 20 Jan 2009 20:16:40 -0800 ebied...@xmission.com (Eric W. Biederman) wrote: > KAMEZAWA Hiroyuki writes: > > > What makes me confused is "Container". There is no "Container" in > > the linux kernel, just cgroup and its subsyss. > > (Some sou

[Devel] Re: [RFC] [PATCH] Cgroup based OOM killer controller

2009-01-21 Thread KAMEZAWA Hiroyuki
On Wed, 21 Jan 2009 12:49:50 -0800 (PST) David Rientjes wrote: > On Wed, 21 Jan 2009, Nikanth Karthikesan wrote: > > > This is a container group based approach to override the oom killer > > selection > > without losing all the benefits of the current oom killer heuristics and > > oom_adj int

[Devel] Re: [RFC] [PATCH] Cgroup based OOM killer controller

2009-01-21 Thread KAMEZAWA Hiroyuki
On Wed, 21 Jan 2009 16:38:21 +0530 Nikanth Karthikesan wrote: > As Alan Cox suggested/wondered in this thread, > http://lkml.org/lkml/2009/1/12/235 , this is a container group based approach > to override the oom killer selection without losing all the benefits of the > current oom killer heur

[Devel] Re: [RFC] [PATCH] Cgroup based OOM killer controller

2009-01-21 Thread KAMEZAWA Hiroyuki
On Thu, 22 Jan 2009 10:43:12 +0530 Nikanth Karthikesan wrote: > On Thursday 22 January 2009 08:58:43 KAMEZAWA Hiroyuki wrote: > > On Wed, 21 Jan 2009 16:38:21 +0530 > > > > Nikanth Karthikesan wrote: > > > As Alan Cox suggested/wondered in this thread, > >

[Devel] Re: cgroup mount point

2009-02-02 Thread KAMEZAWA Hiroyuki
On Mon, 02 Feb 2009 16:54:58 -0600 "Chris Friesen" wrote: > Thadeu Lima de Souza Cascardo wrote: > > > Linux Documentation is not consistent and have some funny options. In > > Documentation/cgroups/*, we have: > > > So, we have some more options now: /cgroups, /containers, /dev/cpuset, > > /de

[Devel] Question for remount

2009-02-20 Thread KAMEZAWA Hiroyuki
Followings are 3 stories of remount cgroup, 1. remount with devices. # mount -t cgroup none /cgroups -ocpuacct,release_agent=xxx # echo > /cgroups/release_agent #clear release agent by hand # mount -t cgroup none /cgroups -oremount,cpuacct # cat /cgroups/release_agent => release_agent is

[Devel] Re: Question for remount

2009-02-20 Thread KAMEZAWA Hiroyuki
Paul Menage さんは書きました: > On Fri, Feb 20, 2009 at 2:02 AM, KAMEZAWA Hiroyuki > wrote: >> >> 2. /proc/mounts information of release_agent should be updated >> when it's overwritten directly. > > Yes, definitely. But shouldn't that happen already? >

[Devel] Re: Question for remount

2009-02-23 Thread KAMEZAWA Hiroyuki
On Mon, 23 Feb 2009 10:32:46 +0800 Li Zefan wrote: > KAMEZAWA Hiroyuki wrote: > > Paul Menage さんは書きました: > >> On Fri, Feb 20, 2009 at 2:02 AM, KAMEZAWA Hiroyuki > >> wrote: > >>> 2. /proc/mounts information of release_agent should be updated > >

[Devel] Re: Question for remount

2009-02-23 Thread KAMEZAWA Hiroyuki
On Mon, 23 Feb 2009 10:56:04 +0800 Li Zefan wrote: > Li Zefan wrote: > >> 1. Documentation/cgroups/cgroup.txt says > >>#mount -oremount,cpuset,ns /dev/cgroup > >>But this should be > >>#mount -tcgroup none /dev/cgroup -oremount,cpuset,ns > >> > > > > I agree. Actually I noticed this

[Devel] Re: Question for remount

2009-02-23 Thread KAMEZAWA Hiroyuki
On Tue, 24 Feb 2009 09:41:28 +0800 Li Zefan wrote: > >> To change the set of subsystems bound to a mounted hierarchy, just > >> remount with different options: > >> +# mount -o remount,cpuset,ns hier1 /dev/cgroup > >> > >> -# mount -o remount,cpuset,ns /dev/cgroup > >> +Now numtasks is remov

[Devel] Re: [PATCH] cgroups: more documentation for remount and release_agent

2009-02-23 Thread KAMEZAWA Hiroyuki
> > And this will get you right: > # mount [-t cgroup] -o remount,cpu xxx /mnt > > Also document how to specify or change release_agent. > > Signed-off-by: Li Zefan Seems nice! Thank you. Reviewd-by: KAMEZAWA Hiroyuki > --- > Documentation/cgroups/cgroups.txt

[Devel] ctop: a tool like top for cgroup

2009-02-24 Thread KAMEZAWA Hiroyuki
Hi, Attached files are script to show information on console by curses. written in ruby. - ctop.rb - cgroup.rb How to use 0. mount some cgroup (cpu,memory,cpuacct,cpuset subsystems are supported) 1. put ctop.rb and cgroup.rb to a directory. 2. ruby ctop.rb 3. read help (No Manuals..) I wro

[Devel] [PATCH 2/2] cgroup/memcg show correct file mode

2009-02-24 Thread KAMEZAWA Hiroyuki
From: KAMEZAWA Hiroyuki Set correct permission to memcg's file. Signed-off-by: KAMEZAWA Hiroyuki --- mm/memcontrol.c |4 1 file changed, 4 insertions(+) Index: mmotm-2.6.29-Feb24/mm/memcontrol.c === --- mmotm-2

[Devel] [PATCH 1/2] cgroup allow subsys to set default mode of its own file

2009-02-24 Thread KAMEZAWA Hiroyuki
From: KAMEZAWA Hiroyuki cgroup's subsys has "readonly" files, but default permission is always rw-r--r--. This allows to create r--r--r-- file to subsys. (The user can do chmod on this read-only file. But this behavior is not different from current pseudo file systems as /proc.)

[Devel] Re: [PATCH 1/2] cgroup allow subsys to set default mode of its own file

2009-02-26 Thread KAMEZAWA Hiroyuki
On Thu, 26 Feb 2009 13:00:05 -0800 Andrew Morton wrote: > On Wed, 25 Feb 2009 16:35:55 +0900 > KAMEZAWA Hiroyuki wrote: > > > When I wrote tools for maintain cgroup, I can't find which file is > > writable intarfece or not via cgroup file systems. (finally,

[Devel] Re: [PATCH 1/2] cgroup allow subsys to set default mode of its own file

2009-02-26 Thread KAMEZAWA Hiroyuki
On Thu, 26 Feb 2009 16:28:11 -0800 Paul Menage wrote: > On Thu, Feb 26, 2009 at 1:00 PM, Andrew Morton > wrote: > > On Wed, 25 Feb 2009 16:35:55 +0900 > > KAMEZAWA Hiroyuki wrote: > > > >> When I wrote tools for maintain cgroup, I can't find which file

[Devel] Re: [PATCH 0/4] cgroups: show correct file mode

2009-03-02 Thread KAMEZAWA Hiroyuki
On Mon, 2 Mar 2009 10:19:15 -0800 Paul Menage wrote: > On Sun, Mar 1, 2009 at 6:13 PM, Li Zefan wrote: > > Now a cgroup subsystem can set default file mode of its control files, > > so here is a patchset to correct file mode of each subsystem's files. > > I really think that we should be defaul

[Devel] Re: [PATCH 0/4] cgroups: show correct file mode

2009-03-02 Thread KAMEZAWA Hiroyuki
On Mon, 2 Mar 2009 16:15:51 -0800 Paul Menage wrote: > On Mon, Mar 2, 2009 at 4:09 PM, KAMEZAWA Hiroyuki > wrote: > > > >int mode; > >if (cft->mode) > >mode = cft->mode; > >else if (cft->write_xxx || .) &g

[Devel] Re: [PATCH 0/4] cgroups: show correct file mode

2009-03-02 Thread KAMEZAWA Hiroyuki
On Tue, 03 Mar 2009 09:08:23 +0800 Li Zefan wrote: > Paul Menage wrote: > > On Sun, Mar 1, 2009 at 6:13 PM, Li Zefan wrote: > >> Now a cgroup subsystem can set default file mode of its control files, > >> so here is a patchset to correct file mode of each subsystem's files. > > > > I really thi

[Devel] Re: [PATCH 0/4] cgroups: show correct file mode

2009-03-02 Thread KAMEZAWA Hiroyuki
= 0444; > >> + > >> + if (cft->write || cft->write_u64 || cft->write_s64 || > >> + cft->write_string || cft->trigger) > >> + mode += 0200; > >> + > > > > += is not |=... > > > > Ah, yes, though bot

[Devel] Re: [PATCH] cgroups: show correct file mode, fix

2009-03-03 Thread KAMEZAWA Hiroyuki
On Wed, 04 Mar 2009 09:52:57 +0800 Li Zefan wrote: > - 'mode' should have type mode_t > - use S_IRUGO/S_IWUSR instead of 0444/0200 > > Signed-off-by: Li Zefan Thank you for quick work. I'll write memcg part on this. Reviewed-by: KAMEZAWA Hiroyuki > --- >

[Devel] Re: [PATCH] cgroups: show correct file mode, fix

2009-03-03 Thread KAMEZAWA Hiroyuki
On Wed, 04 Mar 2009 09:59:53 +0800 Li Zefan wrote: > KAMEZAWA Hiroyuki wrote: > > On Wed, 04 Mar 2009 09:52:57 +0800 > > Li Zefan wrote: > > > >> - 'mode' should have type mode_t > >> - use S_IRUGO/S_IWUSR instead of 0444/0200 > >>

[Devel] Re: [PATCH 0/7][RFC] CGroup hierarchy extensions

2009-03-15 Thread KAMEZAWA Hiroyuki
On Thu, 12 Mar 2009 03:51:16 -0700 Paul Menage wrote: > The following series implements support for: > > - named cgroup hierarchies > - cgroup hierarchies with no bound subsystems > - cgroup subsystems that can be bound to multiple hierarchies > > These patches aren't yet very well tested (only

[Devel] Re: [PATCH 3/9] bio-cgroup controller

2009-04-14 Thread KAMEZAWA Hiroyuki
On Tue, 14 Apr 2009 22:21:14 +0200 Andrea Righi wrote: > From: Ryo Tsuruta > > From: Ryo Tsuruta > > With writeback IO processed asynchronously by kernel threads (pdflush) > the real writes to the underlying block devices can occur in a different > IO context respect to the task that original

[Devel] Re: [PATCH 3/9] bio-cgroup controller

2009-04-15 Thread KAMEZAWA Hiroyuki
On Wed, 15 Apr 2009 15:23:57 +0200 Andrea Righi wrote: > On Wed, Apr 15, 2009 at 09:38:50PM +0900, Ryo Tsuruta wrote: > > Hi Andrea and Kamezawa-san, > > > > > Ryo, it would be great if you can look at this and fix/integrate into > > > the mainstream bio-cgroup. Otherwise I can try to to schedul

[Devel] Re: [PATCH 3/9] bio-cgroup controller

2009-04-16 Thread KAMEZAWA Hiroyuki
On Thu, 16 Apr 2009 12:42:36 +0200 Andrea Righi wrote: > On Thu, Apr 16, 2009 at 08:58:14AM +0900, KAMEZAWA Hiroyuki wrote: > > On Wed, 15 Apr 2009 15:23:57 +0200 > > Andrea Righi wrote: > > > > > On Wed, Apr 15, 2009 at 09:38:50PM +0900, Ryo Tsuruta wrote: >

[Devel] Re: [PATCH 3/9] bio-cgroup controller

2009-04-16 Thread KAMEZAWA Hiroyuki
On Thu, 16 Apr 2009 15:29:37 -0700 Andrew Morton wrote: > On Tue, 14 Apr 2009 22:21:14 +0200 > Andrea Righi wrote: > > > Subject: [PATCH 3/9] bio-cgroup controller > > Sorry, but I have to register extreme distress at the name of this. > The term "bio" is well-established in the kernel and he

[Devel] Re: [PATCH 1/9] io-throttle documentation

2009-04-16 Thread KAMEZAWA Hiroyuki
On Tue, 14 Apr 2009 22:21:12 +0200 Andrea Righi wrote: > +Example: > +* Create an association between an io-throttle group and a bio-cgroup group > + with "bio" and "blockio" subsystems mounted in different mount points: > + # mount -t cgroup -o bio bio-cgroup /mnt/bio-cgroup/ > + # cd /mnt/bi

[Devel] Re: [PATCH 3/9] bio-cgroup controller

2009-04-16 Thread KAMEZAWA Hiroyuki
On Fri, 17 Apr 2009 10:49:43 +0900 Takuya Yoshikawa wrote: > Hi, > > I have a few question. >- I have not yet fully understood how your controller are using > bio_cgroup. If my view is wrong please tell me. > > o In my view, bio_cgroup's implementation strongly depends on >page_cgo

[Devel] Re: [PATCH 1/9] io-throttle documentation

2009-04-17 Thread KAMEZAWA Hiroyuki
On Fri, 17 Apr 2009 15:34:53 +0800 Gui Jianfeng wrote: > KAMEZAWA Hiroyuki wrote: > > On Tue, 14 Apr 2009 22:21:12 +0200 > > Andrea Righi wrote: > > > >> +Example: > >> +* Create an association between an io-throttle group and a bio-cgroup >

[Devel] Re: [PATCH 3/9] bio-cgroup controller

2009-04-17 Thread KAMEZAWA Hiroyuki
On Fri, 17 Apr 2009 16:22:01 +0900 (JST) Ryo Tsuruta wrote: > In the case where the bio-cgroup data is allocated dynamically, >- Sometimes quite a large amount of memory get marked dirty. > In this case it requires more kernel memory than that of the > current implementation. >-

[Devel] Re: [PATCH 3/9] bio-cgroup controller

2009-04-17 Thread KAMEZAWA Hiroyuki
On Fri, 17 Apr 2009 17:00:16 +0900 KAMEZAWA Hiroyuki wrote: > On Fri, 17 Apr 2009 16:22:01 +0900 (JST) > Ryo Tsuruta wrote: > > > In the case where the bio-cgroup data is allocated dynamically, > >- Sometimes quite a large amount of memory get marked dirty. >

[Devel] Re: [PATCH 3/9] bio-cgroup controller

2009-04-17 Thread KAMEZAWA Hiroyuki
On Fri, 17 Apr 2009 17:48:54 +0900 KAMEZAWA Hiroyuki wrote: > On Fri, 17 Apr 2009 17:00:16 +0900 > KAMEZAWA Hiroyuki wrote: > > > On Fri, 17 Apr 2009 16:22:01 +0900 (JST) > > Ryo Tsuruta wrote: > > > > > In the case where the bio-cgroup data is allocat

[Devel] Re: [PATCH 2/7] res_counter: introduce ratelimiting attributes

2009-04-20 Thread KAMEZAWA Hiroyuki
On Sat, 18 Apr 2009 23:38:27 +0200 Andrea Righi wrote: > Introduce attributes and functions in res_counter to implement > throttling-based > cgroup subsystems. > > The following attributes have been added to struct res_counter: > * @policy: the limiting policy / algorithm > * @capacity:

[Devel] Re: IO controller discussion (Was: Re: [PATCH 01/10] Documentation)

2009-04-20 Thread KAMEZAWA Hiroyuki
On Sun, 19 Apr 2009 17:53:59 +0200 Andrea Righi wrote: > > > > Got a question for you. Does memory controller already have the per cgroup > > dirty pages limit? If no, has this been discussed in the past? if yes, > > what was the conclsion? > IMHO, dirty page handling and I/O throttling is a di

[Devel] Re: [PATCH 2/7] res_counter: introduce ratelimiting attributes

2009-04-21 Thread KAMEZAWA Hiroyuki
Andrea Righi wrote: > On Tue, Apr 21, 2009 at 09:15:34AM +0900, KAMEZAWA Hiroyuki wrote: >> It's very bad if cacheline of spinlock is different from data field, in >> future. > > Regarding the new attributes, policy can be surely an unsigned int or > even less (now o

[Devel] Re: [PATCH 9/9] ext3: do not throttle metadata and journal IO

2009-04-21 Thread KAMEZAWA Hiroyuki
On Tue, 21 Apr 2009 22:49:06 +0200 Andrea Righi wrote: > yep! right. Anyway, it's not completely wrong to account dirty pages in > this way. The dirty pages actually belong to cgroup A and providing per > cgroup upper limits of dirty pages could help to equally distribute > dirty pages, that are h

[Devel] Re: [PATCH 9/9] ext3: do not throttle metadata and journal IO

2009-04-21 Thread KAMEZAWA Hiroyuki
On Wed, 22 Apr 2009 09:33:49 +0900 KAMEZAWA Hiroyuki wrote: > > And this should be probably strictly connected to the IO controller. If > > we throttle or delay the dispatching/submission of some IO requests > > without throttling the dirty pages rate a cgroup could completely

[Devel] Re: [PATCH 9/9] ext3: do not throttle metadata and journal IO

2009-04-22 Thread KAMEZAWA Hiroyuki
On Wed, 22 Apr 2009 12:22:41 +0200 Andrea Righi wrote: > Actually I was proposing something quite similar, if I've understood > well. Just add a hook in balance_dirty_pages() to throttle tasks in > cgroups that exhausted their IO BW. > > The way to do so will be similar to the per-bdi write thr

[Devel] Re: [PATCH 9/9] ext3: do not throttle metadata and journal IO

2009-04-22 Thread KAMEZAWA Hiroyuki
On Wed, 22 Apr 2009 21:22:54 -0400 Theodore Tso wrote: > On Thu, Apr 23, 2009 at 09:05:35AM +0900, KAMEZAWA Hiroyuki wrote: > > So, current status is. > > > > A. memcg should support dirty_ratio for its own memory reclaim. > > in plan. > > > >

[Devel] Re: [PATCH 9/9] ext3: do not throttle metadata and journal IO

2009-04-22 Thread KAMEZAWA Hiroyuki
On Wed, 22 Apr 2009 21:58:25 -0700 Andrew Morton wrote: > > Or at least that *someone* is > > doing so and can perhaps document how all of these knobs interact. > > After all, if they are going to be separate, and someone turns the I/O > > throttling knob without bothering to turn the write throt

[Devel] Re: [PATCH 9/9] ext3: do not throttle metadata and journal IO

2009-04-23 Thread KAMEZAWA Hiroyuki
On Thu, 23 Apr 2009 23:13:04 +0200 Andrea Righi wrote: > On Thu, Apr 23, 2009 at 08:17:45AM -0400, Theodore Tso wrote: > > On Thu, Apr 23, 2009 at 11:44:24AM +0200, Andrea Righi wrote: > > > This is true in part. Actually io-throttle v12 has been largely tested, > > > also in production environme

[Devel] [RFC] memory controller : backgorund reclaim and avoid excessive locking [0/5]

2008-02-14 Thread KAMEZAWA Hiroyuki
Hi, these are patches on my stack, now. I believe test is not enough. Maybe there is BUG. Before updating patches, I'd like to hear guys' advice against my concept before going further. TODO: - test on NUMA (machine is not avilable in these days. but I will do) This series inludes 2 series of

[Devel] [RFC] memory controller : backgorund reclaim and avoid excessive locking [2/5] background reclaim.

2008-02-14 Thread KAMEZAWA Hiroyuki
er than res->lwmark. Maybe we can add more tunings but no extra params now. ChangeLog: - start "memcontd" at first change in hwmark. (In old verion, it started at cgroup creation.) - changed "relax" logic in memcontd daemon. Signed-off-by: KAMEZAWA Hiroyuki &l

[Devel] [RFC] memory controller : backgorund reclaim and avoid excessive locking [1/5] high-low watermark

2008-02-14 Thread KAMEZAWA Hiroyuki
r background jobs... If I have to check under lock, please teach me. counter->hwmark and counter->lwmark is not automatically adjusted when limit is changed. So, users must change lwmark, hwmark before changing limit. Changelog * made variable names shorter. * adjusted to 2.6.24-mm1 Signe

[Devel] [RFC] memory controller : backgorund reclaim and avoid excessive locking [4/5] borrow resource

2008-02-14 Thread KAMEZAWA Hiroyuki
One of contended lock is counter->lock. Now, counter->usage is changed by PAGE_SIZE. This patch changes this to be PAGE_SIZE * borrow_factor and cache "borrow" in per cpu area. This reduce # of lock against counter->lock. Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PRO

[Devel] [RFC] memory controller : backgorund reclaim and avoid excessive locking [3/5] throttling

2008-02-14 Thread KAMEZAWA Hiroyuki
omtically estimated value ? (I used '# of cpus/4' as default in previous version.) Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> mm/memcontrol.c | 235 ++-- 1 files changed, 127 insertions(+), 108 deletions(-)

[Devel] [RFC] memory controller : backgorund reclaim and avoid excessive locking [5/5] lazy page_cgroup freeing

2008-02-14 Thread KAMEZAWA Hiroyuki
tch adds a new flag page_cgroup and make lru scan routine ignores it. I think this reduces lock contention especially when - several tasks are exiting at once. - several files are removed at once. Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> mm/memcontrol

[Devel] Re: [RFC] memory controller : backgorund reclaim and avoid excessive locking [2/5] background reclaim.

2008-02-14 Thread KAMEZAWA Hiroyuki
On Thu, 14 Feb 2008 14:02:44 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > KAMEZAWA Hiroyuki wrote: > > A patch for background reclaim based on high-low watermak in res_counter. > > The daemon is called as "memcontd", here. > > > > Implements followi

[Devel] Re: [RFC] memory controller : backgorund reclaim and avoid excessive locking [1/5] high-low watermark

2008-02-14 Thread KAMEZAWA Hiroyuki
On Thu, 14 Feb 2008 14:18:33 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > > If I have to check under lock, please teach me. > > > > If there are several processes running in parallel in the same cgroup, the end > result might not be so nice, specially if the usage is close to the > watermarks

[Devel] Re: [RFC] memory controller : backgorund reclaim and avoid excessive locking [3/5] throttling

2008-02-14 Thread KAMEZAWA Hiroyuki
On Thu, 14 Feb 2008 14:44:50 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > > By this interface, a user can control the # of threads which can enter > > try_to_free... > > > > What happens to the other threads, do they sleep? > yes. > > Default is 10240 ...a enough big number for unlimited. Ma

[Devel] Re: [RFC][PATCH 0/7] CGroup API: More structured API for CGroups control files

2008-02-15 Thread KAMEZAWA Hiroyuki
On Fri, 15 Feb 2008 12:44:18 -0800 Paul Menage <[EMAIL PROTECTED]> wrote: > > This set of patches makes the Control Groups API more structured and > self-describing. > > 1) Allows control files to be associated with data types such as > "u64", "string", "map", etc. These types show up in a new c

[Devel] Re: [RFC] memory controller : backgorund reclaim and avoid excessive locking [4/5] borrow resource

2008-02-17 Thread KAMEZAWA Hiroyuki
On Mon, 18 Feb 2008 09:53:35 +0900 (JST) [EMAIL PROTECTED] (YAMAMOTO Takashi) wrote: > > + /* try to charge */ > > + ret = res_counter_charge(&mem->res, mem->borrow_unit); > > + if (!ret) { /* success */ > > + *bwp += (mem->borrow_unit - size); > > +

[Devel] Re: [RFC] memory controller : backgorund reclaim and avoid excessive locking [5/5] lazy page_cgroup freeing

2008-02-17 Thread KAMEZAWA Hiroyuki
On Mon, 18 Feb 2008 10:58:40 +0900 (JST) [EMAIL PROTECTED] (YAMAMOTO Takashi) wrote: > > + /* > > +* For lazy freeing (not GC) > > +*/ > > + struct { > > + struct mem_cgroup_per_zone *mz; > > + int num; > > +#define GARBAGE_MAXSIZE(16

[Devel] Re: [RFC] memory controller : backgorund reclaim and avoid excessive locking [5/5] lazy page_cgroup freeing

2008-02-17 Thread KAMEZAWA Hiroyuki
On Mon, 18 Feb 2008 10:05:16 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > Hi, KAMEZAWA-San, > > For this and the next patch, do you know if there is a performance > improvement? > Have we measured it. The complexity of the code seems to be high, want to make > sure it is worth it. I'd like to

[Devel] Re: [PATCH] memcgroup: remove a useless VM_BUG_ON()

2008-02-18 Thread KAMEZAWA Hiroyuki
likely(!PageLRU(page))) > continue; > -- > 1.5.4.rc3 > Acked-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> Thanks, -Kame ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listi

[Devel] Re: [RFC/PATCH] cgroup swap subsystem

2008-03-04 Thread KAMEZAWA Hiroyuki
On Wed, 05 Mar 2008 14:59:05 +0900 Daisuke Nishimura <[EMAIL PROTECTED]> wrote: > #ifdef CONFIG_CGROUP_MEM_CONT > +/* > + * A page_cgroup page is associated with every page descriptor. The > + * page_cgroup helps us identify information about the cgroup > + */ > +struct page_cgroup { > + stru

  1   2   3   4   5   6   7   8   9   >