From: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: KOSAKI Motohiro
<kosaki.motohiro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Peter Zijlstra
<a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>,
Paul Turner <pjt-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org,
Linux Containers
<containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
KAMEZAWA Hiroyuki
<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>,
Balbir Singh
<bsingharora-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Serge Hallyn
<serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
Frederic Weisbecker
<fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: How to draw values for /proc/stat
Date: Sun, 11 Dec 2011 21:48:29 +0100 [thread overview]
Message-ID: <4EE5171D.10905@parallels.com> (raw)
In-Reply-To: <4EE5006F.6070604-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 12/11/2011 08:11 PM, KOSAKI Motohiro wrote:
>
>>>> IOW a /proc namespace coupled to cgroup scope would do what you want.
>>>> Now my head hurts..
>>>
>>> Mine too. The idea is good, but too broad. Boils down to: How do you
>>> couple them? And none of the methods I thought about seemed to make any
>>> sense.
>>>
>>> If we really want to have the values in /proc being opted-in, I think
>>> Kamezawa's idea of a mount option is the winner so far.
>
> > diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> > index 1b7f9d5..f0bc2e9 100644
> > --- a/include/linux/cgroup.h
> > +++ b/include/linux/cgroup.h
> > @@ -158,6 +158,7 @@ enum {
> > * Clone cgroup values when creating a new child cgroup
> > */
> > CGRP_CLONE_CHILDREN,
> > + CGRP_PROC_OVERLAY,
> > };
>
> I'm not cgroup expert, but I doubt it is mount option. I suspect it's
> cgroup option. That's said, if we have following two directories,
Actually, the way I proposed, you have both ways. The mount option is
more a default value for convenience, that is effective until you change
a file. That's the same way as clone_children already do, and I believe
it to be a sane thing.
> /cgroup-for-virtualization
> /cgroup-for-resource-management
>
> are both directory affected the overlay flag?
It depends. The flag is per-cgroup, therefore per-directory. So even if
you set the mount option, you can override it in an individual cgroup.
> I don't think it is not
> optimal. Why? we must care some system software (e.g. kvm, systemd) are
> using cgroup internally and we expected this trend will grow more.
As I said before, each directory has its own files, so in a standard
system, we would be more than happy to set it to 1 in the cgroups
corresponding to our containers, and leave the rest of the world alone.
> So, I doubt namespace issue can be solved by such tiny patch.
>
I don't fully get what you mean here
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer@parallels.com>
To: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Turner <pjt@google.com>, <cgroups@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>, <devel@openvz.org>,
Linux Containers <containers@lists.osdl.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Balbir Singh <bsingharora@gmail.com>,
Serge Hallyn <serge.hallyn@canonical.com>,
Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: How to draw values for /proc/stat
Date: Sun, 11 Dec 2011 21:48:29 +0100 [thread overview]
Message-ID: <4EE5171D.10905@parallels.com> (raw)
In-Reply-To: <4EE5006F.6070604@gmail.com>
On 12/11/2011 08:11 PM, KOSAKI Motohiro wrote:
>
>>>> IOW a /proc namespace coupled to cgroup scope would do what you want.
>>>> Now my head hurts..
>>>
>>> Mine too. The idea is good, but too broad. Boils down to: How do you
>>> couple them? And none of the methods I thought about seemed to make any
>>> sense.
>>>
>>> If we really want to have the values in /proc being opted-in, I think
>>> Kamezawa's idea of a mount option is the winner so far.
>
> > diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> > index 1b7f9d5..f0bc2e9 100644
> > --- a/include/linux/cgroup.h
> > +++ b/include/linux/cgroup.h
> > @@ -158,6 +158,7 @@ enum {
> > * Clone cgroup values when creating a new child cgroup
> > */
> > CGRP_CLONE_CHILDREN,
> > + CGRP_PROC_OVERLAY,
> > };
>
> I'm not cgroup expert, but I doubt it is mount option. I suspect it's
> cgroup option. That's said, if we have following two directories,
Actually, the way I proposed, you have both ways. The mount option is
more a default value for convenience, that is effective until you change
a file. That's the same way as clone_children already do, and I believe
it to be a sane thing.
> /cgroup-for-virtualization
> /cgroup-for-resource-management
>
> are both directory affected the overlay flag?
It depends. The flag is per-cgroup, therefore per-directory. So even if
you set the mount option, you can override it in an individual cgroup.
> I don't think it is not
> optimal. Why? we must care some system software (e.g. kvm, systemd) are
> using cgroup internally and we expected this trend will grow more.
As I said before, each directory has its own files, so in a standard
system, we would be more than happy to set it to 1 in the cgroups
corresponding to our containers, and leave the rest of the world alone.
> So, I doubt namespace issue can be solved by such tiny patch.
>
I don't fully get what you mean here
next prev parent reply other threads:[~2011-12-11 20:48 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-05 9:32 How to draw values for /proc/stat Glauber Costa
2011-12-05 9:32 ` Glauber Costa
[not found] ` <4EDC8FB1.60407-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-12-06 0:05 ` KAMEZAWA Hiroyuki
2011-12-06 0:05 ` KAMEZAWA Hiroyuki
[not found] ` <20111206090543.e72128b6.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2011-12-06 0:17 ` Glauber Costa
2011-12-06 0:17 ` Glauber Costa
2011-12-07 14:17 ` Zhu Yanhai
2011-12-07 14:17 ` Zhu Yanhai
2011-12-09 14:07 ` Peter Zijlstra
2011-12-09 14:03 ` Peter Zijlstra
2011-12-09 14:03 ` Peter Zijlstra
2011-12-09 14:55 ` Glauber Costa
2011-12-09 14:55 ` Glauber Costa
[not found] ` <4EE22179.5090106-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-12-11 14:50 ` Glauber Costa
2011-12-11 14:50 ` Glauber Costa
[not found] ` <4EE4C350.90509-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-12-11 19:11 ` KOSAKI Motohiro
2011-12-11 19:11 ` KOSAKI Motohiro
[not found] ` <4EE5006F.6070604-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-12-11 20:48 ` Glauber Costa [this message]
2011-12-11 20:48 ` Glauber Costa
2011-12-12 0:31 ` KAMEZAWA Hiroyuki
2011-12-12 0:31 ` KAMEZAWA Hiroyuki
[not found] ` <20111212093116.96537551.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2011-12-12 7:06 ` Glauber Costa
2011-12-12 7:06 ` Glauber Costa
[not found] ` <4EE5A7FA.8050707-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-12-12 8:22 ` Glauber Costa
2011-12-12 8:22 ` Glauber Costa
2011-12-12 9:33 ` Peter Zijlstra
2011-12-12 9:33 ` Peter Zijlstra
2011-12-12 9:35 ` Glauber Costa
2011-12-12 9:35 ` Glauber Costa
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=4EE5171D.10905@parallels.com \
--to=glommer-bzqdu9zft3wakbo8gow8eq@public.gmane.org \
--cc=a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org \
--cc=bsingharora-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
--cc=kosaki.motohiro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=pjt-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.