linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Paul Menage <menage@google.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"containers@lists.osdl.org" <containers@lists.osdl.org>,
	"balbir@linux.vnet.ibm.com" <balbir@linux.vnet.ibm.com>,
	"xemul@openvz.org" <xemul@openvz.org>,
	"nishimura@mxp.nes.nec.co.jp" <nishimura@mxp.nes.nec.co.jp>,
	"yamamoto@valinux.co.jp" <yamamoto@valinux.co.jp>
Subject: Re: [RFD][PATCH] memcg: Move Usage at Task Move
Date: Thu, 12 Jun 2008 14:08:06 +0900	[thread overview]
Message-ID: <20080612140806.dc161c77.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <6599ad830806110148v65df67f8ge0ccdd56c21c89e0@mail.gmail.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.

Just a question:
What happens when a thread (not thread-group-leader) changes its ns by
ns-cgroup ? not-allowed ?


Thanks,
-Kame



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-06-12  5:08 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-06  1:52 KAMEZAWA Hiroyuki
2008-06-10  5:50 ` YAMAMOTO Takashi
2008-06-10  8:13   ` KAMEZAWA Hiroyuki
2008-06-10 12:57     ` YAMAMOTO Takashi
2008-06-11  2:02       ` KAMEZAWA Hiroyuki
2008-06-11  3:45         ` YAMAMOTO Takashi
2008-06-11  4:08           ` KAMEZAWA Hiroyuki
2008-06-10  7:35 ` Daisuke Nishimura
2008-06-10  8:26   ` KAMEZAWA Hiroyuki
2008-06-11  3:03     ` Daisuke Nishimura
2008-06-11  3:25       ` KAMEZAWA Hiroyuki
2008-06-11  3:44         ` YAMAMOTO Takashi
2008-06-11  4:14           ` KAMEZAWA Hiroyuki
2008-06-11  4:29             ` Daisuke Nishimura
2008-06-11  4:40               ` KAMEZAWA Hiroyuki
2008-06-12  5:20             ` YAMAMOTO Takashi
2008-06-12  6:51               ` KAMEZAWA Hiroyuki
2008-06-11  7:17 ` Paul Menage
2008-06-11  7:45   ` KAMEZAWA Hiroyuki
2008-06-11  8:04     ` Paul Menage
2008-06-11  8:27       ` KAMEZAWA Hiroyuki
2008-06-11  8:48         ` Paul Menage
2008-06-12  5:08           ` KAMEZAWA Hiroyuki [this message]
2008-06-12 13:17             ` Serge E. Hallyn
2008-06-12 13:34             ` kamezawa.hiroyu
2008-06-12 21:08               ` Serge E. Hallyn
2008-06-13  0:34                 ` KAMEZAWA Hiroyuki
2008-06-13  0:41                   ` KAMEZAWA Hiroyuki
2008-06-11  8:27   ` Balbir Singh
2008-06-11 12:21     ` Daisuke Nishimura
2008-06-11 12:51     ` kamezawa.hiroyu
2008-06-11 13:13       ` Balbir Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080612140806.dc161c77.kamezawa.hiroyu@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=containers@lists.osdl.org \
    --cc=linux-mm@kvack.org \
    --cc=menage@google.com \
    --cc=nishimura@mxp.nes.nec.co.jp \
    --cc=xemul@openvz.org \
    --cc=yamamoto@valinux.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox