OpenVZ Forum - RDF feed
type: channel
items: [RFD][PATCH] memcg: Move Usage at Task Move
items: Re: [RFD][PATCH] memcg: Move Usage at Task Move
items: Re: Re: [RFD][PATCH] memcg: Move Usage at Task Move

[RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: Move Usage at Task Move (just an experimantal for discussion) I tested this but don't think bug-free. In current memcg, when task moves to a new cg, the usage remains in the old cg. This is considered to be not good. This is a trial to move "usage" from old cg to new cg at task move. Finally, you'll see the problems we have to handle are failure and rollback. This one's Basic algorithm is 0. can_attach() is called. 1. count movable pages by scanning page table. isolate all pages from LRU. 2. try to create enough room in new memory cgroup 3. start moving page accouing 4. putback pages to LRU. 5. can_attach() for other cgroups are called. A case study. group_A -> limit=1G, task_X's usage= 800M. group_B -> limit=1G, usage=500M. For moving task_X from group_A to group_B. - group_B should be reclaimed or have enough room. While moving task_X from group_A to group_B. - group_B's memory usage can be changed - group_A's memory usage can be changed We accounts the resouce based on pages. Then, we can't move all resource usage at once. If group_B has no more room when we've moved 700M of task_X to group_B, we have to move 700M of task_X back to group_A. So I implemented roll-back. But other process may use up group_A's available resource at that point. For avoiding that, preserve 800M in group_B before moving task_X means that task_X can occupy 1600M of resource at moving. (So I don't do in this patch.) This patch uses Best-Effort rollback. Failure in rollback is ignored and the usage is just leaked. Roll-back can happen when (a) in phase 3. cannot move a page to new cgroup because of limit. (b) in phase 5. other cgourp subsys returns error in can_attach(). Rollback (a) is handled in memcg, but there is a chance for leak of accounting at rollback. To handle rollback (b), attach_rollback() is added to cgroup_ops. (If memcg is the last subysys, handling (b) is not necessary.) I wonder what kind of technique can we use to avoid complicated situation.... For avoiding complicated …
creator: KAMEZAWA Hiroyuki
date: 2008-06-06T01:52:35-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: > For avoiding complicated rollbacks, > I think of following ways of policy for task moving (you can add here.) > > 1. Before moving usage, reserve usage in the new cgroup and old cgroup. > Pros. > - rollback will be very easy. > Cons. > - A task will use twice of its own usage virtaually for a while. > - some amount of cpu time will be necessary to move _Big_ apps. > - It's difficut to move _Big_ apps to small memcg. > - we have to add "special case" handling. > > 2. Don't move any usage at task move. (current implementation.) > Pros. > - no complication in the code. > Cons. > - A task's usage is chareged to wrong cgroup. > - Not sure, but I believe the users don't want this. > > 3. Use Lazy Manner > When the task moves, we can mark the pages used by it as > "Wrong Charge, Should be dropped", and add them some penalty in the LRU. > Pros. > - no complicated ones. > - the pages will be gradually moved at memory pressure. > Cons. > - A task's usage can exceed the limit for a while. > - can't handle mlocked() memory in proper way. > > 4. Allow Half-moved state and abandon rollback. > Pros. > - no complicated ones in the code. > Cons. > - the users will be in chaos. how about: 5. try to move charges as your patch does. if the target cgroup's usage is going to exceed the limit, try to shrink it. if it failed, just leave it exceeded. (ie. no rollback) for the memory subsystem, which can use its OOM killer, the failure should be rare. > After writing this patch, for me, "3" is attractive. now. > (or using Lazy manner and allow moving of usage instead of freeing it.) > > One reasone is that I think a typical usage of memory controller is > fork()->move->exec(). (by libcg ?) and exec() will flush the all usage. i guess that moving long-running applications can be desirable esp. for not so well-designed systems. YAMAMOTO Takashi _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mail…
creator: yamamoto
date: 2008-06-10T05:50:32-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: Hi, Kamezawa-san. Sorry for late reply. On Fri, 6 Jun 2008 10:52:35 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > Move Usage at Task Move (just an experimantal for discussion) > I tested this but don't think bug-free. > > In current memcg, when task moves to a new cg, the usage remains in the old cg. > This is considered to be not good. > I agree. > This is a trial to move "usage" from old cg to new cg at task move. > Finally, you'll see the problems we have to handle are failure and rollback. > > This one's Basic algorithm is > > 0. can_attach() is called. > 1. count movable pages by scanning page table. isolate all pages from LRU. > 2. try to create enough room in new memory cgroup > 3. start moving page accouing > 4. putback pages to LRU. > 5. can_attach() for other cgroups are called. > You isolate pages and move charges of them by can_attach(), but it means that pages that are allocated between page isolation and moving tsk->cgroups remains charged to old group, right? I think it would be better if possible to move charges by attach() as cpuset migrates pages by cpuset_attach(). But one of the problem of it is that attch() does not return any value, so there is no way to notify failure... > A case study. > > group_A -> limit=1G, task_X's usage= 800M. > group_B -> limit=1G, usage=500M. > > For moving task_X from group_A to group_B. > - group_B should be reclaimed or have enough room. > > While moving task_X from group_A to group_B. > - group_B's memory usage can be changed > - group_A's memory usage can be changed > > We accounts the resouce based on pages. Then, we can't move all resource > usage at once. > > If group_B has no more room when we've moved 700M of task_X to group_B, > we have to move 700M of task_X back to group_A. So I implemented roll-back. > But other process may use up group_A's available resource at that point. > > For avoiding that, preserve 800M in group_B before moving task_X means that > task_X can occupy 1600M of res…
creator: Daisuke Nishimura
date: 2008-06-10T07:35:50-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Tue, 10 Jun 2008 14:50:32 +0900 (JST) yamamoto@valinux.co.jp (YAMAMOTO Takashi) wrote: > > 3. Use Lazy Manner > > When the task moves, we can mark the pages used by it as > > "Wrong Charge, Should be dropped", and add them some penalty in the LRU. > > Pros. > > - no complicated ones. > > - the pages will be gradually moved at memory pressure. > > Cons. > > - A task's usage can exceed the limit for a while. > > - can't handle mlocked() memory in proper way. > > > > 4. Allow Half-moved state and abandon rollback. > > Pros. > > - no complicated ones in the code. > > Cons. > > - the users will be in chaos. > > how about: > > 5. try to move charges as your patch does. > if the target cgroup's usage is going to exceed the limit, > try to shrink it. if it failed, just leave it exceeded. > (ie. no rollback) > for the memory subsystem, which can use its OOM killer, > the failure should be rare. > Hmm, allowing exceed and cause OOM kill ? One difficult point is that the users cannot know they can move task without any risk. How to handle the risk can be a point. I don't like that approarch in general because I don't like "exceed" status. But implementation will be easy. > > After writing this patch, for me, "3" is attractive. now. > > (or using Lazy manner and allow moving of usage instead of freeing it.) > > > > One reasone is that I think a typical usage of memory controller is > > fork()->move->exec(). (by libcg ?) and exec() will flush the all usage. > > i guess that moving long-running applications can be desirable > esp. for not so well-designed systems. > hmm, for not so well-designed systems....true. But "5" has the same kind of risks for not so well-desgined systems ;) Thanks, -Kame _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: KAMEZAWA Hiroyuki
date: 2008-06-10T08:11:26-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Tue, 10 Jun 2008 16:35:50 +0900 Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> wrote: > Hi, Kamezawa-san. > > Sorry for late reply. > > On Fri, 6 Jun 2008 10:52:35 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > Move Usage at Task Move (just an experimantal for discussion) > > I tested this but don't think bug-free. > > > > In current memcg, when task moves to a new cg, the usage remains in the old cg. > > This is considered to be not good. > > > I agree. > > > This is a trial to move "usage" from old cg to new cg at task move. > > Finally, you'll see the problems we have to handle are failure and rollback. > > > > This one's Basic algorithm is > > > > 0. can_attach() is called. > > 1. count movable pages by scanning page table. isolate all pages from LRU. > > 2. try to create enough room in new memory cgroup > > 3. start moving page accouing > > 4. putback pages to LRU. > > 5. can_attach() for other cgroups are called. > > > You isolate pages and move charges of them by can_attach(), > but it means that pages that are allocated between page isolation > and moving tsk->cgroups remains charged to old group, right? yes. > > I think it would be better if possible to move charges by attach() > as cpuset migrates pages by cpuset_attach(). > But one of the problem of it is that attch() does not return > any value, so there is no way to notify failure... > yes, here again. it makes roll-back more difficult. > > A case study. > > > > group_A -> limit=1G, task_X's usage= 800M. > > group_B -> limit=1G, usage=500M. > > > > For moving task_X from group_A to group_B. > > - group_B should be reclaimed or have enough room. > > > > While moving task_X from group_A to group_B. > > - group_B's memory usage can be changed > > - group_A's memory usage can be changed > > > > We accounts the resouce based on pages. Then, we can't move all resource > > usage at once. > > > > If group_B has no more room when we've moved 700M of task_X to group_B, > > we have to mov…
creator: KAMEZAWA Hiroyuki
date: 2008-06-10T08:24:41-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: > On Tue, 10 Jun 2008 14:50:32 +0900 (JST) > yamamoto@valinux.co.jp (YAMAMOTO Takashi) wrote: > > > > 3. Use Lazy Manner > > > When the task moves, we can mark the pages used by it as > > > "Wrong Charge, Should be dropped", and add them some penalty in the LRU. > > > Pros. > > > - no complicated ones. > > > - the pages will be gradually moved at memory pressure. > > > Cons. > > > - A task's usage can exceed the limit for a while. > > > - can't handle mlocked() memory in proper way. > > > > > > 4. Allow Half-moved state and abandon rollback. > > > Pros. > > > - no complicated ones in the code. > > > Cons. > > > - the users will be in chaos. > > > > how about: > > > > 5. try to move charges as your patch does. > > if the target cgroup's usage is going to exceed the limit, > > try to shrink it. if it failed, just leave it exceeded. > > (ie. no rollback) > > for the memory subsystem, which can use its OOM killer, > > the failure should be rare. > > > > Hmm, allowing exceed and cause OOM kill ? > > One difficult point is that the users cannot know they can move task > without any risk. How to handle the risk can be a point. > I don't like that approarch in general because I don't like "exceed" > status. But implementation will be easy. regardless of how to handle task moves, it's important to provide information to help users to avoid unreasonable cgroup/task placement. otherwise, they will be surprised by OOM-killer etc anyway. having said that, if you decide to put too large tasks into a cgroup with too small limit, i don't think that there are many choices besides OOM-kill and allowing "exceed". actually, i think that #3 and #5 are somewhat similar. a big difference is that, while #5 shrinks the cgroup immediately, #3 does it later. in case we need to do OOM-kill, i prefer to do it sooner than later. > > > After writing this patch, for me, "3" is attractive. now. > > > (or using Lazy manner and allow moving of usage instead of freeing it.) > > > > > > One reasone is …
creator: yamamoto
date: 2008-06-10T12:57:03-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Tue, 10 Jun 2008 21:57:03 +0900 (JST) yamamoto@valinux.co.jp (YAMAMOTO Takashi) wrote: > > > 5. try to move charges as your patch does. > > > if the target cgroup's usage is going to exceed the limit, > > > try to shrink it. if it failed, just leave it exceeded. > > > (ie. no rollback) > > > for the memory subsystem, which can use its OOM killer, > > > the failure should be rare. > > > > > > > Hmm, allowing exceed and cause OOM kill ? > > > > One difficult point is that the users cannot know they can move task > > without any risk. How to handle the risk can be a point. > > I don't like that approarch in general because I don't like "exceed" > > status. But implementation will be easy. > > regardless of how to handle task moves, > it's important to provide information to help users > to avoid unreasonable cgroup/task placement. > otherwise, they will be surprised by OOM-killer etc anyway. > yes. > having said that, if you decide to put too large tasks into > a cgroup with too small limit, i don't think that there are > many choices besides OOM-kill and allowing "exceed". > IMHO, allowing exceed is harmfull without changing the definition of "limit". "limit" is hard-limit, now, not soft-limit. Changing the defintion just for this is not acceptable for me. Maybe "move" under limit itself is crazy ops....Hmm... Should we allow task move when the destination cgroup is unlimited ? Isn't it useful ? > actually, i think that #3 and #5 are somewhat similar. > a big difference is that, while #5 shrinks the cgroup immediately, > #3 does it later. in case we need to do OOM-kill, i prefer to do it > sooner than later. > #3 will not cause OOM-killer, I hope...A user can notice memory shortage. > > > > After writing this patch, for me, "3" is attractive. now. > > > > (or using Lazy manner and allow moving of usage instead of freeing it.) > > > > > > > > One reasone is that I think a typical usage of memory controller is > > > > fork()->move->exec(). (by libcg ?) and exec() wil…
creator: KAMEZAWA Hiroyuki
date: 2008-06-11T01:58:41-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Tue, 10 Jun 2008 17:26:37 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > This is a trial to move "usage" from old cg to new cg at task move. > > > Finally, you'll see the problems we have to handle are failure and rollback. > > > > > > This one's Basic algorithm is > > > > > > 0. can_attach() is called. > > > 1. count movable pages by scanning page table. isolate all pages from LRU. > > > 2. try to create enough room in new memory cgroup > > > 3. start moving page accouing > > > 4. putback pages to LRU. > > > 5. can_attach() for other cgroups are called. > > > > > You isolate pages and move charges of them by can_attach(), > > but it means that pages that are allocated between page isolation > > and moving tsk->cgroups remains charged to old group, right? > yes. > > > > > I think it would be better if possible to move charges by attach() > > as cpuset migrates pages by cpuset_attach(). > > But one of the problem of it is that attch() does not return > > any value, so there is no way to notify failure... > > > yes, here again. it makes roll-back more difficult. > I think so too. That's why I said "one of the problem". > > > A case study. > > > > > > group_A -> limit=1G, task_X's usage= 800M. > > > group_B -> limit=1G, usage=500M. > > > > > > For moving task_X from group_A to group_B. > > > - group_B should be reclaimed or have enough room. > > > > > > While moving task_X from group_A to group_B. > > > - group_B's memory usage can be changed > > > - group_A's memory usage can be changed > > > > > > We accounts the resouce based on pages. Then, we can't move all resource > > > usage at once. > > > > > > If group_B has no more room when we've moved 700M of task_X to group_B, > > > we have to move 700M of task_X back to group_A. So I implemented roll-back. > > > But other process may use up group_A's available resource at that point. > > > > > > For avoiding that, preserve 800M in group_B before moving task_X means that > > > task_X can occupy …
creator: Daisuke Nishimura
date: 2008-06-11T03:03:45-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Wed, 11 Jun 2008 12:03:45 +0900 Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> wrote: > > > Or, instead of implementing rollback in kernel, > > > how about making user(or middle ware?) re-echo pid to rollbak > > > on failure? > > > > > > > "If the users does well, the system works in better way" is O.K. > > "If the users doesn't well, the system works in broken way" is very bad. > > > Hum... > > I think users must know what they are doing. > yes. but it's a different problem, - "a user must know what they does." - "a system works without BUG even if the user is crazy." > They must know that moving a process to another group > that doesn't have enough room for it may fail with half state, > if it is the behavior of kernel. > And they should handle the error by themselves, IMHO. > I'm now considering following logic. How do you think ? Assume: move TASK from group:CURR to group:DEST. == move_task(TASK, CURR, DEST) if (DEST's limit is unlimited) moving TASK return success. usage = check_usage_of_task(TASK). /* try to reserve enough room in destionation */ if (try_to_reserve_enough_room(DEST, usage)) { move TASK to DEST and move pages AMAP. /* usage_of_task(TASK) can be changed while we do this. Then, we move AMAP. */ return success; } return failure. == The difficult point will be reservation but can be implemented without complexity. Thanks, -Kame _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: KAMEZAWA Hiroyuki
date: 2008-06-11T03:24:56-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: > I'm now considering following logic. How do you think ? > > Assume: move TASK from group:CURR to group:DEST. > > == move_task(TASK, CURR, DEST) > > if (DEST's limit is unlimited) > moving TASK > return success. > > usage = check_usage_of_task(TASK). > > /* try to reserve enough room in destionation */ > if (try_to_reserve_enough_room(DEST, usage)) { > move TASK to DEST and move pages AMAP. > /* usage_of_task(TASK) can be changed while we do this. > Then, we move AMAP. */ > return success; > } > return failure. > == AMAP means that you might leave some random charges in CURR? i think that you can redirect new charges in TASK to DEST so that usage_of_task(TASK) will not grow. YAMAMOTO Takashi _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: yamamoto
date: 2008-06-11T03:44:46-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: > > having said that, if you decide to put too large tasks into > > a cgroup with too small limit, i don't think that there are > > many choices besides OOM-kill and allowing "exceed". > > > IMHO, allowing exceed is harmfull without changing the definition of "limit". > "limit" is hard-limit, now, not soft-limit. Changing the defintion just for > this is not acceptable for me. even with the current code, the "exceed" condition can be created by simply lowering the limit. (well, i know that some of your patches floating around change it.) > Maybe "move" under limit itself is crazy ops....Hmm... > > Should we allow task move when the destination cgroup is unlimited ? > Isn't it useful ? i think it makes some sense. > > actually, i think that #3 and #5 are somewhat similar. > > a big difference is that, while #5 shrinks the cgroup immediately, > > #3 does it later. in case we need to do OOM-kill, i prefer to do it > > sooner than later. > > > #3 will not cause OOM-killer, I hope...A user can notice memory shortage. we are talking about the case where a cgroup's working set is getting hopelessly larger than its limit. i don't see why #3 will not cause OOM-kill. can you explain? YAMAMOTO Takashi _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: yamamoto
date: 2008-06-11T03:45:14-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Wed, 11 Jun 2008 12:45:14 +0900 (JST) yamamoto@valinux.co.jp (YAMAMOTO Takashi) wrote: > > > having said that, if you decide to put too large tasks into > > > a cgroup with too small limit, i don't think that there are > > > many choices besides OOM-kill and allowing "exceed". > > > > > IMHO, allowing exceed is harmfull without changing the definition of "limit". > > "limit" is hard-limit, now, not soft-limit. Changing the defintion just for > > this is not acceptable for me. > > even with the current code, the "exceed" condition can be created > by simply lowering the limit. > (well, i know that some of your patches floating around change it.) > Yes, I write it now ;) Handling exceed contains some troubles - when resizing limit, to what extent exceed is allowed ? - Once exceed, no new page allocation can success and _some random process_ will die because of OOM. > > Maybe "move" under limit itself is crazy ops....Hmm... > > > > Should we allow task move when the destination cgroup is unlimited ? > > Isn't it useful ? > > i think it makes some sense. > > > > actually, i think that #3 and #5 are somewhat similar. > > > a big difference is that, while #5 shrinks the cgroup immediately, > > > #3 does it later. in case we need to do OOM-kill, i prefer to do it > > > sooner than later. > > > > > #3 will not cause OOM-killer, I hope...A user can notice memory shortage. > > we are talking about the case where a cgroup's working set is getting > hopelessly larger than its limit. i don't see why #3 will not > cause OOM-kill. can you explain? > just because #3 doesn't move resource, just drop. Thanks, -Kame _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: KAMEZAWA Hiroyuki
date: 2008-06-11T04:05:32-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Wed, 11 Jun 2008 12:44:46 +0900 (JST) yamamoto@valinux.co.jp (YAMAMOTO Takashi) wrote: > > I'm now considering following logic. How do you think ? > > > > Assume: move TASK from group:CURR to group:DEST. > > > > == move_task(TASK, CURR, DEST) > > > > if (DEST's limit is unlimited) > > moving TASK > > return success. > > > > usage = check_usage_of_task(TASK). > > > > /* try to reserve enough room in destionation */ > > if (try_to_reserve_enough_room(DEST, usage)) { > > move TASK to DEST and move pages AMAP. > > /* usage_of_task(TASK) can be changed while we do this. > > Then, we move AMAP. */ > > return success; > > } > > return failure. > > == > > AMAP means that you might leave some random charges in CURR? > yes. but we can reduce bad case by some way - reserve more than necessary. or - read_lock mm->sem while move. > i think that you can redirect new charges in TASK to DEST > so that usage_of_task(TASK) will not grow. > Hmm, to do that, we have to handle complicated cgroup's attach ops. at this moving, memcg is pointed by - TASK->cgroup->memcg(CURR) after move - TASK->another_cgroup->memcg(DEST) This move happens before cgroup is replaced by another_cgroup. Thanks, -Kame _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: KAMEZAWA Hiroyuki
date: 2008-06-11T04:14:37-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Wed, 11 Jun 2008 13:14:37 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > On Wed, 11 Jun 2008 12:44:46 +0900 (JST) > yamamoto@valinux.co.jp (YAMAMOTO Takashi) wrote: > > > > I'm now considering following logic. How do you think ? > > > > > > Assume: move TASK from group:CURR to group:DEST. > > > > > > == move_task(TASK, CURR, DEST) > > > > > > if (DEST's limit is unlimited) > > > moving TASK > > > return success. > > > > > > usage = check_usage_of_task(TASK). > > > > > > /* try to reserve enough room in destionation */ > > > if (try_to_reserve_enough_room(DEST, usage)) { > > > move TASK to DEST and move pages AMAP. > > > /* usage_of_task(TASK) can be changed while we do this. > > > Then, we move AMAP. */ > > > return success; > > > } > > > return failure. > > > == > > > > AMAP means that you might leave some random charges in CURR? > > > yes. but we can reduce bad case by some way > - reserve more than necessary. > or > - read_lock mm->sem while move. > I preffer the latter. Though it's expencive, I think moving a task would not happen so offen. Thanks, Daisuke Nishimura. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Daisuke Nishimura
date: 2008-06-11T04:29:09-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Wed, 11 Jun 2008 13:29:09 +0900 Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> wrote: > On Wed, 11 Jun 2008 13:14:37 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > On Wed, 11 Jun 2008 12:44:46 +0900 (JST) > > yamamoto@valinux.co.jp (YAMAMOTO Takashi) wrote: > > > > > > I'm now considering following logic. How do you think ? > > > > > > > > Assume: move TASK from group:CURR to group:DEST. > > > > > > > > == move_task(TASK, CURR, DEST) > > > > > > > > if (DEST's limit is unlimited) > > > > moving TASK > > > > return success. > > > > > > > > usage = check_usage_of_task(TASK). > > > > > > > > /* try to reserve enough room in destionation */ > > > > if (try_to_reserve_enough_room(DEST, usage)) { > > > > move TASK to DEST and move pages AMAP. > > > > /* usage_of_task(TASK) can be changed while we do this. > > > > Then, we move AMAP. */ > > > > return success; > > > > } > > > > return failure. > > > > == > > > > > > AMAP means that you might leave some random charges in CURR? > > > > > yes. but we can reduce bad case by some way > > - reserve more than necessary. > > or > > - read_lock mm->sem while move. > > > I preffer the latter. > Though it's expencive, I think moving a task would not happen > so offen. > Sure. I'd like to write one and post as RFC. (hopefully in this week) Thanks, -Kame _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: KAMEZAWA Hiroyuki
date: 2008-06-11T04:37:10-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Thu, Jun 5, 2008 at 6:52 PM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > Move Usage at Task Move (just an experimantal for discussion) > I tested this but don't think bug-free. > > In current memcg, when task moves to a new cg, the usage remains in the old cg. > This is considered to be not good. Is it really such a big deal if we don't transfer the page ownerships to the new cgroup? As this thread has shown, it's a fairly painful operation to support. It would be good to have some concrete examples of cases where this is needed. > > This is a trial to move "usage" from old cg to new cg at task move. > Finally, you'll see the problems we have to handle are failure and rollback. > > This one's Basic algorithm is > > 0. can_attach() is called. > 1. count movable pages by scanning page table. isolate all pages from LRU. > 2. try to create enough room in new memory cgroup > 3. start moving page accouing > 4. putback pages to LRU. > 5. can_attach() for other cgroups are called. > > A case study. > > group_A -> limit=1G, task_X's usage= 800M. > group_B -> limit=1G, usage=500M. > > For moving task_X from group_A to group_B. > - group_B should be reclaimed or have enough room. > > While moving task_X from group_A to group_B. > - group_B's memory usage can be changed > - group_A's memory usage can be changed > > We accounts the resouce based on pages. Then, we can't move all resource > usage at once. > > If group_B has no more room when we've moved 700M of task_X to group_B, > we have to move 700M of task_X back to group_A. So I implemented roll-back. > But other process may use up group_A's available resource at that point. > > For avoiding that, preserve 800M in group_B before moving task_X means that > task_X can occupy 1600M of resource at moving. (So I don't do in this patch.) I think that pre-reserving in B would be the cleanest solution, and would save the need to provide rollback. > 2. Don't move any usage at task move. (current implementation.) > …
creator: Paul Menage
date: 2008-06-11T07:17:31-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: Hi, On Wed, 11 Jun 2008 00:17:31 -0700 "Paul Menage" <menage@google.com> wrote: > On Thu, Jun 5, 2008 at 6:52 PM, KAMEZAWA Hiroyuki > <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > Move Usage at Task Move (just an experimantal for discussion) > > I tested this but don't think bug-free. > > > > In current memcg, when task moves to a new cg, the usage remains in the old cg. > > This is considered to be not good. > > Is it really such a big deal if we don't transfer the page ownerships > to the new cgroup? As this thread has shown, it's a fairly painful > operation to support. It would be good to have some concrete examples > of cases where this is needed. > When we moves a process with XXXG bytes of memory, we need "move" obviously. I think there is a case that system administrator decides to create _new_ cgroup to isolate some swappy job for maintaining the system. (I never be able to say that never happens.) This kind of resource resizing can be happen under automatic controlls of middleware, I think. But as you say, this should be implemented in simple way. I'm now trying to make this simple. (i.e. searching no-rollback approach.) > > > > This is a trial to move "usage" from old cg to new cg at task move. > > Finally, you'll see the problems we have to handle are failure and rollback. > > > > This one's Basic algorithm is > > > > 0. can_attach() is called. > > 1. count movable pages by scanning page table. isolate all pages from LRU. > > 2. try to create enough room in new memory cgroup > > 3. start moving page accouing > > 4. putback pages to LRU. > > 5. can_attach() for other cgroups are called. > > > > A case study. > > > > group_A -> limit=1G, task_X's usage= 800M. > > group_B -> limit=1G, usage=500M. > > > > For moving task_X from group_A to group_B. > > - group_B should be reclaimed or have enough room. > > > > While moving task_X from group_A to group_B. > > - group_B's memory usage can be changed > > - group_A's memory usage can be changed > > > > We accounts …
creator: KAMEZAWA Hiroyuki
date: 2008-06-11T07:42:12-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Wed, Jun 11, 2008 at 12:45 AM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: >> Is it really such a big deal if we don't transfer the page ownerships >> to the new cgroup? As this thread has shown, it's a fairly painful >> operation to support. It would be good to have some concrete examples >> of cases where this is needed. >> > When we moves a process with XXXG bytes of memory, we need "move" obviously. That's not a concrete example, it's an assertion :-) > > I think there is a case that system administrator decides to create _new_ > cgroup to isolate some swappy job for maintaining the system. > (I never be able to say that never happens.) OK, that seems like a reasonable case - i.e. when an existing cgroup is deliberately split into two. An alternative way to support that would be to do nothing at move time, but provide a "pull_usage" control file that would slurp any pages in any mm in the cgroup into the cgroup. >> > >> > One reasone is that I think a typical usage of memory controller is >> > fork()->move->exec(). (by libcg ?) and exec() will flush the all usage. >> >> Exactly - this is a good reason *not* to implement move - because then >> you drag all the usage of the middleware daemon into the new cgroup. >> > Yes but this is one of the usage of cgroup. In general, system admin can > use this for limiting memory on his own decision. > Sorry, your last sentence doesn't make sense to me in this context. If the common mode for middleware starting a new cgroup is fork() / move / exec() then after the fork(), the child will be sharing pages with the main daemon process. So the move will pull all the daemon's memory into the new cgroup > yes. but, at first, I'll try no-rollback approach. > And can I move memory resource controller's subsys_id to the last for now ? > That's probably fine for experimentation, but it wouldn't be something we'd want to commit to -mm or mainline. Paul _______________________________________________ Containers mailing …
creator: Paul Menage
date: 2008-06-11T08:04:14-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Wed, 11 Jun 2008 01:04:14 -0700 "Paul Menage" <menage@google.com> wrote: > An alternative way to support that would be to do nothing at move > time, but provide a "pull_usage" control file that would slurp any > pages in any mm in the cgroup into the cgroup. > >> > > >> > One reasone is that I think a typical usage of memory controller is > >> > fork()->move->exec(). (by libcg ?) and exec() will flush the all usage. > >> > >> Exactly - this is a good reason *not* to implement move - because then > >> you drag all the usage of the middleware daemon into the new cgroup. > >> > > Yes but this is one of the usage of cgroup. In general, system admin can > > use this for limiting memory on his own decision. > > > > Sorry, your last sentence doesn't make sense to me in this context. > Sorry. try another sentense.. I think cgroup itself is designed to be able to be used without middleware. IOW, whether using middleware or not is the matter of users not of developpers. There will be a system that system admin controlles all and move tasks by hand. ex)...personal notebooks etc.. > If the common mode for middleware starting a new cgroup is fork() / > move / exec() then after the fork(), the child will be sharing pages > with the main daemon process. So the move will pull all the daemon's > memory into the new cgroup > My patch (this patch) just moves Private Anon page to new cgroup. (of mapcount=1) > > yes. but, at first, I'll try no-rollback approach. > > And can I move memory resource controller's subsys_id to the last for now ? > > > > That's probably fine for experimentation, but it wouldn't be something > we'd want to commit to -mm or mainline. > Hmm, I'd like to post a patch to add "rollback" to cgroup if I find it necessary. My first purpose of this post is showing the problem and starting discussion. Anyway, I will remove "RFC" only when I got enough number of Acks. Thanks, -Kame _______________________________________________ Containers mailing list Containers@list…
creator: KAMEZAWA Hiroyuki
date: 2008-06-11T08:26:37-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: Paul Menage wrote: > On Thu, Jun 5, 2008 at 6:52 PM, KAMEZAWA Hiroyuki > <kamezawa.hiroyu@jp.fujitsu.com> wrote: >> Move Usage at Task Move (just an experimantal for discussion) >> I tested this but don't think bug-free. >> >> In current memcg, when task moves to a new cg, the usage remains in the old cg. >> This is considered to be not good. > > Is it really such a big deal if we don't transfer the page ownerships > to the new cgroup? As this thread has shown, it's a fairly painful > operation to support. It would be good to have some concrete examples > of cases where this is needed. > > I tend to agree with Paul. One of the reasons, I did not move charges is that makes migration an expensive operation. Since migration is well controlled with permissions, we assume that the node owner what he/she is doing. >> This is a trial to move "usage" from old cg to new cg at task move. >> Finally, you'll see the problems we have to handle are failure and rollback. >> >> This one's Basic algorithm is >> >> 0. can_attach() is called. >> 1. count movable pages by scanning page table. isolate all pages from LRU. >> 2. try to create enough room in new memory cgroup >> 3. start moving page accouing >> 4. putback pages to LRU. >> 5. can_attach() for other cgroups are called. >> >> A case study. >> >> group_A -> limit=1G, task_X's usage= 800M. >> group_B -> limit=1G, usage=500M. >> >> For moving task_X from group_A to group_B. >> - group_B should be reclaimed or have enough room. >> >> While moving task_X from group_A to group_B. >> - group_B's memory usage can be changed >> - group_A's memory usage can be changed >> >> We accounts the resouce based on pages. Then, we can't move all resource >> usage at once. >> >> If group_B has no more room when we've moved 700M of task_X to group_B, >> we have to move 700M of task_X back to group_A. So I implemented roll-back. >> But other process may use up group_A's available resource at that point. >> >> For avoiding that, preserve 800M in gr…
creator: Balbir Singh
date: 2008-06-11T08:27:34-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Wed, Jun 11, 2008 at 1:27 AM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > Sorry. try another sentense.. > > I think cgroup itself is designed to be able to be used without middleware. True, but it shouldn't be hostile to middleware, since I think that automated use will be much more common. (And certainly if you count the number of servers :-) ) > IOW, whether using middleware or not is the matter of users not of developpers. > There will be a system that system admin controlles all and move tasks by hand. > ex)...personal notebooks etc.. > You think so? I think that at the very least users will be using tools based around config scripts, rule engines and libcgroup, if not a persistent daemon. >> If the common mode for middleware starting a new cgroup is fork() / >> move / exec() then after the fork(), the child will be sharing pages >> with the main daemon process. So the move will pull all the daemon's >> memory into the new cgroup >> > My patch (this patch) just moves Private Anon page to new cgroup. (of mapcount=1) OK, well that makes it more reasonable regarding the above problem. But I can still see problems if, say, a single thread moves into a new cgroup, you move the entire memory. Perhaps you should only do so if the mm->owner changes task? Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2008-06-11T08:48:20-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Wed, 11 Jun 2008 13:57:34 +0530 Balbir Singh <balbir@linux.vnet.ibm.com> wrote: (snip) > >> 2. Don't move any usage at task move. (current implementation.) > >> Pros. > >> - no complication in the code. > >> Cons. > >> - A task's usage is chareged to wrong cgroup. > >> - Not sure, but I believe the users don't want this. > > > > I'd say stick with this unless there a strong arguments in favour of > > changing, based on concrete needs. > > > >> One reasone is that I think a typical usage of memory controller is > >> fork()->move->exec(). (by libcg ?) and exec() will flush the all usage. > > > > Exactly - this is a good reason *not* to implement move - because then > > you drag all the usage of the middleware daemon into the new cgroup. > > > > Yes. The other thing is that charges will eventually fade away. Please see the > cgroup implementation of page_referenced() and mark_page_accessed(). The > original group on memory pressure will drop pages that were left behind by a > task that migrates. The new group will pick it up if referenced. > Hum.. So, it seems that some kind of "Lazy Mode"(#3 of Kamezawa-san's) has been implemented already. But, one of the reason that I think usage should be moved is to make the usage as accurate as possible, that is the size of memory used by processes in the group at the moment. I agree that statistics is not the purpose of memcg(and swap), but, IMHO, it's useful feature of memcg. Administrators can know how busy or idle each groups are by it. Thanks, Daisuke Nishimura. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Daisuke Nishimura
date: 2008-06-11T12:21:26-00:00

Re: Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: ----- Original Message ----- >On Wed, 11 Jun 2008 13:57:34 +0530 >Balbir Singh <balbir@linux.vnet.ibm.com> wrote: > >(snip) > >> >> 2. Don't move any usage at task move. (current implementation.) >> >> Pros. >> >> - no complication in the code. >> >> Cons. >> >> - A task's usage is chareged to wrong cgroup. >> >> - Not sure, but I believe the users don't want this. >> > >> > I'd say stick with this unless there a strong arguments in favour of >> > changing, based on concrete needs. >> > >> >> One reasone is that I think a typical usage of memory controller is >> >> fork()->move->exec(). (by libcg ?) and exec() will flush the all usage. >> > >> > Exactly - this is a good reason *not* to implement move - because then >> > you drag all the usage of the middleware daemon into the new cgroup. >> > >> >> Yes. The other thing is that charges will eventually fade away. Please see the >> cgroup implementation of page_referenced() and mark_page_accessed(). The >> original group on memory pressure will drop pages that were left behind by a >> task that migrates. The new group will pick it up if referenced. >> >Hum.. >So, it seems that some kind of "Lazy Mode"(#3 of Kamezawa-san's) >has been implemented already. > >But, one of the reason that I think usage should be moved >is to make the usage as accurate as possible, that is >the size of memory used by processes in the group at the moment. > >I agree that statistics is not the purpose of memcg(and swap), >but, IMHO, it's useful feature of memcg. >Administrators can know how busy or idle each groups are by it. > One more point. This kinds of lazy "drop" approach canoot works well when there are mlocked processes. lazy "move" approarch is better if we do in lazy way. And how quickly they drops depends on vm.swappiness. Anyway, I don't like complicated logic in the kernel. So, let's see how simple "move" can be implemented. Then, it will be just a trade-off problem, IMHO. If policy is fixed, implementation itself will not be comp…
creator: KAMEZAWA Hiroyuki
date: 2008-06-11T12:51:03-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: kamezawa.hiroyu@jp.fujitsu.com wrote: > ----- Original Message ----- >> On Wed, 11 Jun 2008 13:57:34 +0530 >> Balbir Singh <balbir@linux.vnet.ibm.com> wrote: >> >> (snip) >> >>>>> 2. Don't move any usage at task move. (current implementation.) >>>>> Pros. >>>>> - no complication in the code. >>>>> Cons. >>>>> - A task's usage is chareged to wrong cgroup. >>>>> - Not sure, but I believe the users don't want this. >>>> I'd say stick with this unless there a strong arguments in favour of >>>> changing, based on concrete needs. >>>> >>>>> One reasone is that I think a typical usage of memory controller is >>>>> fork()->move->exec(). (by libcg ?) and exec() will flush the all usage. >>>> Exactly - this is a good reason *not* to implement move - because then >>>> you drag all the usage of the middleware daemon into the new cgroup. >>>> >>> Yes. The other thing is that charges will eventually fade away. Please see > the >>> cgroup implementation of page_referenced() and mark_page_accessed(). The >>> original group on memory pressure will drop pages that were left behind by > a >>> task that migrates. The new group will pick it up if referenced. >>> >> Hum.. >> So, it seems that some kind of "Lazy Mode"(#3 of Kamezawa-san's) >> has been implemented already. >> >> But, one of the reason that I think usage should be moved >> is to make the usage as accurate as possible, that is >> the size of memory used by processes in the group at the moment. >> >> I agree that statistics is not the purpose of memcg(and swap), >> but, IMHO, it's useful feature of memcg. >> Administrators can know how busy or idle each groups are by it. >> > One more point. This kinds of lazy "drop" approach canoot works well when > there are mlocked processes. lazy "move" approarch is better if we do in lazy > way. And how quickly they drops depends on vm.swappiness. > > Anyway, I don't like complicated logic in the kernel. > So, let's see how simple "move" can be implemented. Then, it will be just a > trad…
creator: Balbir Singh
date: 2008-06-11T13:13:38-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Wed, 11 Jun 2008 01:48:20 -0700 "Paul Menage" <menage@google.com> wrote: > On Wed, Jun 11, 2008 at 1:27 AM, KAMEZAWA Hiroyuki > <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > Sorry. try another sentense.. > > > > I think cgroup itself is designed to be able to be used without middleware. > > True, but it shouldn't be hostile to middleware, since I think that > automated use will be much more common. (And certainly if you count > the number of servers :-) ) > > > IOW, whether using middleware or not is the matter of users not of developpers. > > There will be a system that system admin controlles all and move tasks by hand. > > ex)...personal notebooks etc.. > > > > You think so? I think that at the very least users will be using tools > based around config scripts, rule engines and libcgroup, if not a > persistent daemon. > I believe some users will never use middlewares because of their special usage of linux. > >> If the common mode for middleware starting a new cgroup is fork() / > >> move / exec() then after the fork(), the child will be sharing pages > >> with the main daemon process. So the move will pull all the daemon's > >> memory into the new cgroup > >> > > My patch (this patch) just moves Private Anon page to new cgroup. (of mapcount=1) > > OK, well that makes it more reasonable regarding the above problem. > But I can still see problems if, say, a single thread moves into a new > cgroup, you move the entire memory. Perhaps you should only do so if > the mm->owner changes task? > Thank you for pointing out. I'll add mm->owner check. BTW, should we have a cgroup for SYSVIPC resource controller and devide it from memory resource controller ? I think that per-task on-demand usage accounting is not suitable for shmem (and hugepage). per-creater (caller of shmget()) accounting seems to be better for me. Just a question: What happens when a thread (not thread-group-leader) changes its ns by ns-cgroup ? not-allowed ? Thanks, -Kame ______________________________…
creator: KAMEZAWA Hiroyuki
date: 2008-06-12T05:05:33-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: > > i think that you can redirect new charges in TASK to DEST > > so that usage_of_task(TASK) will not grow. > > > > Hmm, to do that, we have to handle complicated cgroup's attach ops. > > at this moving, memcg is pointed by > - TASK->cgroup->memcg(CURR) > after move > - TASK->another_cgroup->memcg(DEST) > > This move happens before cgroup is replaced by another_cgroup. currently cgroup_attach_task calls ->attach callbacks after assigning tsk->cgroups. are you talking about something else? YAMAMOTO Takashi _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: yamamoto
date: 2008-06-12T05:20:33-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Thu, 12 Jun 2008 14:20:33 +0900 (JST) yamamoto@valinux.co.jp (YAMAMOTO Takashi) wrote: > > > i think that you can redirect new charges in TASK to DEST > > > so that usage_of_task(TASK) will not grow. > > > > > > > Hmm, to do that, we have to handle complicated cgroup's attach ops. > > > > at this moving, memcg is pointed by > > - TASK->cgroup->memcg(CURR) > > after move > > - TASK->another_cgroup->memcg(DEST) > > > > This move happens before cgroup is replaced by another_cgroup. > > currently cgroup_attach_task calls ->attach callbacks after > assigning tsk->cgroups. are you talking about something else? > Sorry, I move all in can_attach(). s/attach/can_attach Thanks, -Kame _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: KAMEZAWA Hiroyuki
date: 2008-06-12T06:50:35-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: Quoting KAMEZAWA Hiroyuki (kamezawa.hiroyu@jp.fujitsu.com): > On Wed, 11 Jun 2008 01:48:20 -0700 > "Paul Menage" <menage@google.com> wrote: > > > On Wed, Jun 11, 2008 at 1:27 AM, KAMEZAWA Hiroyuki > > <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > Sorry. try another sentense.. > > > > > > I think cgroup itself is designed to be able to be used without middleware. > > > > True, but it shouldn't be hostile to middleware, since I think that > > automated use will be much more common. (And certainly if you count > > the number of servers :-) ) > > > > > IOW, whether using middleware or not is the matter of users not of developpers. > > > There will be a system that system admin controlles all and move tasks by hand. > > > ex)...personal notebooks etc.. > > > > > > > You think so? I think that at the very least users will be using tools > > based around config scripts, rule engines and libcgroup, if not a > > persistent daemon. > > > I believe some users will never use middlewares because of their special > usage of linux. > > > > > >> If the common mode for middleware starting a new cgroup is fork() / > > >> move / exec() then after the fork(), the child will be sharing pages > > >> with the main daemon process. So the move will pull all the daemon's > > >> memory into the new cgroup > > >> > > > My patch (this patch) just moves Private Anon page to new cgroup. (of mapcount=1) > > > > OK, well that makes it more reasonable regarding the above problem. > > But I can still see problems if, say, a single thread moves into a new > > cgroup, you move the entire memory. Perhaps you should only do so if > > the mm->owner changes task? > > > > Thank you for pointing out. I'll add mm->owner check. > > BTW, should we have a cgroup for SYSVIPC resource controller and devide it > from memory resource controller ? I think that per-task on-demand usage > accounting is not suitable for shmem (and hugepage). > per-creater (caller of shmget()) accounting seems to be better for me. > > Ju…
creator: serue
date: 2008-06-12T13:17:48-00:00

Re: Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: ----- Original Message ----- >> Just a question: >> What happens when a thread (not thread-group-leader) changes its ns by >> ns-cgroup ? not-allowed ? > >I don't quite understand the question. I assume you're asking whether >your cgroup, when composed with ns, will refuse a task in cgroup /cg/1/2 >from being able to > > mkdir /cg/1/2/3 > echo $$ > /cg/1/2/3/tasks > >or > > unshare(CLONE_NEWNS) > >which the ns cgroup would allow, and what your cgroup would do in that >case. If your question ("not-allowed ?") is about ns cgroup behavior >then please rephrase. Ah, sorry. I'm just curious. (and I should read the code before making quiestion.) Assume a thread group contains threadA, threadB, threadC. I wanted to ask "Can threadA, and threadB, and threadC be in different cgroups ? And if so, how ns cgroup handles it ?" Maybe I don't understand ns cgroup. Thanks, -Kame _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: KAMEZAWA Hiroyuki
date: 2008-06-12T13:34:48-00:00

Re: Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: Quoting kamezawa.hiroyu@jp.fujitsu.com (kamezawa.hiroyu@jp.fujitsu.com): > ----- Original Message ----- > >> Just a question: > >> What happens when a thread (not thread-group-leader) changes its ns by > >> ns-cgroup ? not-allowed ? > > > >I don't quite understand the question. I assume you're asking whether > >your cgroup, when composed with ns, will refuse a task in cgroup /cg/1/2 > >from being able to > > > > mkdir /cg/1/2/3 > > echo $$ > /cg/1/2/3/tasks > > > >or > > > > unshare(CLONE_NEWNS) > > > >which the ns cgroup would allow, and what your cgroup would do in that > >case. If your question ("not-allowed ?") is about ns cgroup behavior > >then please rephrase. > > Ah, sorry. I'm just curious. (and I should read the code before making > quiestion.) > > Assume a thread group contains threadA, threadB, threadC. > > I wanted to ask "Can threadA, and threadB, and threadC > be in different cgroups ? And if so, how ns cgroup handles it ?" > > Maybe I don't understand ns cgroup. In part yes, but nonetheless a very interesting question when it comes to composition of cgroups! Yes, you can have threads in different cgroups. The ns cgroup just tracks nsproxy unshares. So if you run the attached program and look around, you'll see the first thread is in /cg/taskpid while the second one is in /cg/taskpid/secondthreadpid. Clearly, composing this with a cgroup which needs to keep threads in the same cgroup becomes problematic! Interesting :) -serge #include <stdio.h> #include <stdlib.h> #include <sched.h> #include <sys/syscall.h> #include <unistd.h> #include <signal.h> #include <string.h> #include <errno.h> #include <libgen.h> #include <fcntl.h> #include <sys/types.h> #include <sys/wait.h> #include <linux/unistd.h> #ifndef SYS_unshare #ifdef __NR_unshare #define SYS_unshare __NR_unshare #elif __i386__ #define SYS_unshare 310 #elif __ia64__ #define SYS_unshare 1296 #elif __x86_64__ #define SYS_unshare 272 #elif __s390x__ #define SYS_unshare 303 #elif __powerpc__ #define SYS_…
creator: serue
date: 2008-06-12T21:08:12-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Thu, 12 Jun 2008 16:08:12 -0500 "Serge E. Hallyn" <serue@us.ibm.com> wrote: > > Assume a thread group contains threadA, threadB, threadC. > > > > I wanted to ask "Can threadA, and threadB, and threadC > > be in different cgroups ? And if so, how ns cgroup handles it ?" > > > > Maybe I don't understand ns cgroup. > > In part yes, but nonetheless a very interesting question when it comes > to composition of cgroups! > > Yes, you can have threads in different cgroups. The ns cgroup just > tracks nsproxy unshares. So if you run the attached program and look > around, you'll see the first thread is in /cg/taskpid while the second > one is in /cg/taskpid/secondthreadpid. > > Clearly, composing this with a cgroup which needs to keep threads in the > same cgroup becomes problematic! > > Interesting :) > Thank you for kindly explanation. I'll take this into account. I confirmed memory resouce controller should not get tasks's cgroup directly from "task" and should get it from "mm->owner". Thank you. Regards, -Kame _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: KAMEZAWA Hiroyuki
date: 2008-06-13T00:31:12-00:00

Re: [RFD][PATCH] memcg: Move Usage at Task Move
type: item
description: On Fri, 13 Jun 2008 09:34:36 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > Thank you for kindly explanation. I'll take this into account. I confirmed > memory resouce controller should not get tasks's cgroup directly from "task" > and should get it from "mm->owner". > And this means the whole thread group's memory related cgroup can be changed when mm->owner is changed. I'm not sure this is not a problem but it seems complex. Thanks, -Kame _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: KAMEZAWA Hiroyuki
date: 2008-06-13T00:37:43-00:00