OpenVZ Forum - RDF feed
type: channel
items: How to draw values for /proc/stat
items: Re: How to draw values for /proc/stat

How to draw values for /proc/stat
type: item
description: Hi, Specially Peter and Paul, but all the others: As you can see in https://lkml.org/lkml/2011/12/4/178, and in my answer to that, there is a question - one I've asked before but without that much of an audience - of whether /proc files read from process living on cgroups should display global or per-cgroup resources. In the past, I was arguing for a knob to control that, but I recently started to believe that a knob here will only overcomplicate matters: if you live in a cgroup, you should display only the resources you can possibly use. Global is for whoever is in the main cgroup. Now, it comes two questions: 1) Do you agree with that, for files like /proc/stat ? I think the most important part is to be consistent inside the system, regardless of what is done 2) Will cpuacct stay? I think if it does, that becomes almost mandatory (at least the bind mount idea is pretty much over here), because drawing value for /proc/stat becomes quite complex. The cpuacct cgroup can provide user, sys, etc values. But we also have: * nr_context_switches, * jiffies since boot, * total_forks, * nr_running, * nr_iowait, Now I doubt any of us want to see /proc/stat extended to accommodate things like nr_context_switches, or even worse, nr_running. The way I see it, there are two options here: a) moving everything to cpu cgroup so we keep all values being drawn from the same place b) Collect that info from multiple places in a transparent way. ctx, nr_running and nr_iowait will probably come from cpu. jiffies can come from wherever, and maybe we can even draw total_forks from Frederic's and avoid counting it twice.
creator: Glauber Costa
date: 2011-12-05T09:32:33-00:00

Re: How to draw values for /proc/stat
type: item
description: On Mon, 5 Dec 2011 07:32:33 -0200 Glauber Costa <glommer@parallels.com> wrote: > Hi, > > Specially Peter and Paul, but all the others: > > As you can see in https://lkml.org/lkml/2011/12/4/178, and in my answer > to that, there is a question - one I've asked before but without that > much of an audience - of whether /proc files read from process living on > cgroups should display global or per-cgroup resources. > > In the past, I was arguing for a knob to control that, but I recently > started to believe that a knob here will only overcomplicate matters: > if you live in a cgroup, you should display only the resources you can > possibly use. Global is for whoever is in the main cgroup. > Hm. I have a suggestion and a concern. (A suggestion) How about having a mount option for procfs ? For example, mount -t proc .... -o cgroup_virtualized Then, /proc/stat etc shows per-cgroup information. (A concern) /proc/stat will be a mixture of virtualized values and not-virtualized values. 1. Don't users need to know whether each value is virtualized or not ? 2. Can we have a way to show "this value is virtualized!" annotation ? > Now, it comes two questions: > 1) Do you agree with that, for files like /proc/stat ? I think the most > important part is to be consistent inside the system, regardless of what > is done > I think some kind of care for users are required as I wrote above. > 2) Will cpuacct stay? I think if it does, that becomes almost mandatory > (at least the bind mount idea is pretty much over here), because drawing > value for /proc/stat becomes quite complex. > The cpuacct cgroup can provide user, sys, etc values. But we also have: > If virtualized /proc/stat works, I don't think 'account only' cgroup is necessary. It can be obsolete. Thanks, -Kame
creator: KAMEZAWA Hiroyuki
date: 2011-12-06T00:05:43-00:00

Re: How to draw values for /proc/stat
type: item
description: On 12/05/2011 10:05 PM, KAMEZAWA Hiroyuki wrote: > On Mon, 5 Dec 2011 07:32:33 -0200 > Glauber Costa<glommer@parallels.com> wrote: > >> Hi, >> >> Specially Peter and Paul, but all the others: >> >> As you can see in https://lkml.org/lkml/2011/12/4/178, and in my answer >> to that, there is a question - one I've asked before but without that >> much of an audience - of whether /proc files read from process living on >> cgroups should display global or per-cgroup resources. >> >> In the past, I was arguing for a knob to control that, but I recently >> started to believe that a knob here will only overcomplicate matters: >> if you live in a cgroup, you should display only the resources you can >> possibly use. Global is for whoever is in the main cgroup. >> > > Hm. I have a suggestion and a concern. > > (A suggestion) > How about having a mount option for procfs ? > For example, > mount -t proc .... -o cgroup_virtualized > Then, /proc/stat etc shows per-cgroup information. > > (A concern) > /proc/stat will be a mixture of virtualized values and not-virtualized values. > 1. Don't users need to know whether each value is virtualized or not ? > 2. Can we have a way to show "this value is virtualized!" annotation ? A mount options works for me. However, "work" doesn't mean it is really necessary, and that's the real question: is there a real use case for someone resource-constrained to see system-wide values ? What is exactly the expectation here? If you want to see whichever resources you're entitled to, just showing the cgroups version on /proc would be simpler, with less confusion, and do the right thing. As for your concerns: 1) As said above, my point of view is that no, they do not. You only see what you can touch. 2) I think this defeats the goal of transparency. Users of fully virtualized VMs for instances, have no annotations like that (of course it is possible to hint they are virtualized from many other sources). But in the end of the day, a resource is a resour…
creator: Glauber Costa
date: 2011-12-06T00:17:06-00:00

Re: How to draw values for /proc/stat
type: item
description: 2011/12/5 Glauber Costa <glommer@parallels.com>: > Hi, > > Specially Peter and Paul, but all the others: > > As you can see in https://lkml.org/lkml/2011/12/4/178, and in my answer to > that, there is a question - one I've asked before but without that much of > an audience - of whether /proc files read from process living on cgroups > should display global or per-cgroup resources. > > In the past, I was arguing for a knob to control that, but I recently > started to believe that a knob here will only overcomplicate matters: > if you live in a cgroup, you should display only the resources you can > possibly use. Global is for whoever is in the main cgroup. > > Now, it comes two questions: > 1) Do you agree with that, for files like /proc/stat ? I think the most > important part is to be consistent inside the system, regardless of what is > done > > 2) Will cpuacct stay? I think if it does, that becomes almost mandatory (at > least the bind mount idea is pretty much over here), because drawing value > for /proc/stat becomes quite complex. > The cpuacct cgroup can provide user, sys, etc values. But we also have: > > * nr_context_switches, > * jiffies since boot, > * total_forks, > * nr_running, > * nr_iowait, > > Now I doubt any of us want to see /proc/stat extended to accommodate things > like nr_context_switches, or even worse, nr_running. The way I see it, there > are two options here: > > a) moving everything to cpu cgroup so we keep all values being drawn > from the same place > b) Collect that info from multiple places in a transparent way. ctx, > nr_running and nr_iowait will probably come from cpu. jiffies can > come from wherever, and maybe we can even draw total_forks > from Frederic's and avoid counting it twice. > -- > To unsubscribe from this list: send the line "unsubscribe cgroups" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Hi, I think making /proc files read from process l…
creator: Zhu Yanhai
date: 2011-12-07T14:17:51-00:00

Re: How to draw values for /proc/stat
type: item
description: On Mon, 2011-12-05 at 07:32 -0200, Glauber Costa wrote: > Hi, > > Specially Peter and Paul, but all the others: > > As you can see in https://lkml.org/lkml/2011/12/4/178, and in my answer > to that, there is a question - one I've asked before but without that > much of an audience - of whether /proc files read from process living on > cgroups should display global or per-cgroup resources. > > In the past, I was arguing for a knob to control that, but I recently > started to believe that a knob here will only overcomplicate matters: > if you live in a cgroup, you should display only the resources you can > possibly use. Global is for whoever is in the main cgroup. > > Now, it comes two questions: > 1) Do you agree with that, for files like /proc/stat ? I think the most > important part is to be consistent inside the system, regardless of what > is done Personally I don't give a rats arse about (/proc vs) cgroups :-) Currently /proc is unaffected by whatever cgroup you happen to be in and that seems to make some sort of sense. Namespaces seem to be about limiting visibility, cgroups about controlling resources. The two things are hopelessly disjoint atm, but I believe someone was looking at this mess. IOW a /proc namespace coupled to cgroup scope would do what you want. Now my head hurts.. > 2) Will cpuacct stay? I really want to kill it. Balbir seems to want to retain a control-less accounting capability, but I really don't see the point in that. Nor is anybody selling it convincingly. So I think I'll simply deprecate it and schedule it for removal and anybody wanting something like this is free to send patches to implement what they want in the cpu controller and convince me its worth the pain. > I think if it does, that becomes almost mandatory You're referring to #1 here, right? > (at least the bind mount idea is pretty much over here), because drawing > value for /proc/stat becomes quite complex. > The cpuacct cgroup can provide user, sys, etc values. But we also…
creator: Peter Zijlstra
date: 2011-12-09T14:03:31-00:00

Re: How to draw values for /proc/stat
type: item
description: On Wed, 2011-12-07 at 22:17 +0800, Zhu Yanhai wrote: > Let's include lxc-user mailing list for this topic. How many rotten cgroup related lists are there, it already had cgroups@ and containers@, which IMO is 1 too many already.
creator: Peter Zijlstra
date: 2011-12-09T14:07:00-00:00

Re: How to draw values for /proc/stat
type: item
description: On 12/09/2011 12:03 PM, Peter Zijlstra wrote: > On Mon, 2011-12-05 at 07:32 -0200, Glauber Costa wrote: >> Hi, >> >> Specially Peter and Paul, but all the others: >> >> As you can see in https://lkml.org/lkml/2011/12/4/178, and in my answer >> to that, there is a question - one I've asked before but without that >> much of an audience - of whether /proc files read from process living on >> cgroups should display global or per-cgroup resources. >> >> In the past, I was arguing for a knob to control that, but I recently >> started to believe that a knob here will only overcomplicate matters: >> if you live in a cgroup, you should display only the resources you can >> possibly use. Global is for whoever is in the main cgroup. >> >> Now, it comes two questions: >> 1) Do you agree with that, for files like /proc/stat ? I think the most >> important part is to be consistent inside the system, regardless of what >> is done > > Personally I don't give a rats arse about (/proc vs) cgroups :-) > Currently /proc is unaffected by whatever cgroup you happen to be in and > that seems to make some sort of sense. > > Namespaces seem to be about limiting visibility, cgroups about > controlling resources. > > The two things are hopelessly disjoint atm, but I believe someone was > looking at this mess. I did take a look at this (if anyone else was, I'd like to know so we can share some ideas), but I am not convinced we should do anything to join them anymore. We virtualization people are to the best of my knowledge the only ones doing namespaces. Cgroups, OTOH, got a lot bigger. What I am mostly concerned about now, is how consistent they will be. /proc always being always global indeed does make sense, but my question still stands: if you live in a resource-controlled world, why should you even see resources you will never own ? > 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 d…
creator: Glauber Costa
date: 2011-12-09T14:55:53-00:00

Re: How to draw values for /proc/stat
type: item
description: On 12/09/2011 03:55 PM, Glauber Costa wrote: > On 12/09/2011 12:03 PM, Peter Zijlstra wrote: >> On Mon, 2011-12-05 at 07:32 -0200, Glauber Costa wrote: >>> Hi, >>> >>> Specially Peter and Paul, but all the others: >>> >>> As you can see in https://lkml.org/lkml/2011/12/4/178, and in my answer >>> to that, there is a question - one I've asked before but without that >>> much of an audience - of whether /proc files read from process living on >>> cgroups should display global or per-cgroup resources. >>> >>> In the past, I was arguing for a knob to control that, but I recently >>> started to believe that a knob here will only overcomplicate matters: >>> if you live in a cgroup, you should display only the resources you can >>> possibly use. Global is for whoever is in the main cgroup. >>> >>> Now, it comes two questions: >>> 1) Do you agree with that, for files like /proc/stat ? I think the most >>> important part is to be consistent inside the system, regardless of what >>> is done >> >> Personally I don't give a rats arse about (/proc vs) cgroups :-) >> Currently /proc is unaffected by whatever cgroup you happen to be in and >> that seems to make some sort of sense. >> >> Namespaces seem to be about limiting visibility, cgroups about >> controlling resources. >> >> The two things are hopelessly disjoint atm, but I believe someone was >> looking at this mess. > > I did take a look at this (if anyone else was, I'd like to know so we > can share some ideas), but I am not convinced we should do anything to > join them anymore. We virtualization people are to the best of my > knowledge the only ones doing namespaces. Cgroups, OTOH, got a lot bigger. > > What I am mostly concerned about now, is how consistent they will be. > /proc always being always global indeed does make sense, but my question > still stands: if you live in a resource-controlled world, why should you > even see resources you will never own ? > > >> IOW a /proc namespace coupled to cgroup scope would do…
creator: Glauber Costa
date: 2011-12-11T14:50:56-00:00

Re: How to draw values for /proc/stat
type: item
description: >>> 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, /cgroup-for-virtualization /cgroup-for-resource-management are both directory affected the overlay flag? 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. So, I doubt namespace issue can be solved by such tiny patch.
creator: KOSAKI Motohiro
date: 2011-12-11T19:11:43-00:00

Re: How to draw values for /proc/stat
type: item
description: 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
creator: Glauber Costa
date: 2011-12-11T20:48:29-00:00

Re: How to draw values for /proc/stat
type: item
description: On Sun, 11 Dec 2011 15:50:56 +0100 Glauber Costa <glommer@parallels.com> wrote: > On 12/09/2011 03:55 PM, Glauber Costa wrote: > > On 12/09/2011 12:03 PM, Peter Zijlstra wrote: > >> On Mon, 2011-12-05 at 07:32 -0200, Glauber Costa wrote: > >>> Hi, > >>> > >>> Specially Peter and Paul, but all the others: > >>> > >>> As you can see in https://lkml.org/lkml/2011/12/4/178, and in my answer > >>> to that, there is a question - one I've asked before but without that > >>> much of an audience - of whether /proc files read from process living on > >>> cgroups should display global or per-cgroup resources. > >>> > >>> In the past, I was arguing for a knob to control that, but I recently > >>> started to believe that a knob here will only overcomplicate matters: > >>> if you live in a cgroup, you should display only the resources you can > >>> possibly use. Global is for whoever is in the main cgroup. > >>> > >>> Now, it comes two questions: > >>> 1) Do you agree with that, for files like /proc/stat ? I think the most > >>> important part is to be consistent inside the system, regardless of what > >>> is done > >> > >> Personally I don't give a rats arse about (/proc vs) cgroups :-) > >> Currently /proc is unaffected by whatever cgroup you happen to be in and > >> that seems to make some sort of sense. > >> > >> Namespaces seem to be about limiting visibility, cgroups about > >> controlling resources. > >> > >> The two things are hopelessly disjoint atm, but I believe someone was > >> looking at this mess. > > > > I did take a look at this (if anyone else was, I'd like to know so we > > can share some ideas), but I am not convinced we should do anything to > > join them anymore. We virtualization people are to the best of my > > knowledge the only ones doing namespaces. Cgroups, OTOH, got a lot bigger. > > > > What I am mostly concerned about now, is how consistent they will be. > > /proc always being always global indeed does make sense, but my question > > still stands: if…
creator: KAMEZAWA Hiroyuki
date: 2011-12-12T00:31:16-00:00

Re: How to draw values for /proc/stat
type: item
description: On 12/12/2011 04:31 AM, KAMEZAWA Hiroyuki wrote: > On Sun, 11 Dec 2011 15:50:56 +0100 > Glauber Costa<glommer@parallels.com> wrote: > >> On 12/09/2011 03:55 PM, Glauber Costa wrote: >>> On 12/09/2011 12:03 PM, Peter Zijlstra wrote: >>>> On Mon, 2011-12-05 at 07:32 -0200, Glauber Costa wrote: >>>>> Hi, >>>>> >>>>> Specially Peter and Paul, but all the others: >>>>> >>>>> As you can see in https://lkml.org/lkml/2011/12/4/178, and in my answer >>>>> to that, there is a question - one I've asked before but without that >>>>> much of an audience - of whether /proc files read from process living on >>>>> cgroups should display global or per-cgroup resources. >>>>> >>>>> In the past, I was arguing for a knob to control that, but I recently >>>>> started to believe that a knob here will only overcomplicate matters: >>>>> if you live in a cgroup, you should display only the resources you can >>>>> possibly use. Global is for whoever is in the main cgroup. >>>>> >>>>> Now, it comes two questions: >>>>> 1) Do you agree with that, for files like /proc/stat ? I think the most >>>>> important part is to be consistent inside the system, regardless of what >>>>> is done >>>> >>>> Personally I don't give a rats arse about (/proc vs) cgroups :-) >>>> Currently /proc is unaffected by whatever cgroup you happen to be in and >>>> that seems to make some sort of sense. >>>> >>>> Namespaces seem to be about limiting visibility, cgroups about >>>> controlling resources. >>>> >>>> The two things are hopelessly disjoint atm, but I believe someone was >>>> looking at this mess. >>> >>> I did take a look at this (if anyone else was, I'd like to know so we >>> can share some ideas), but I am not convinced we should do anything to >>> join them anymore. We virtualization people are to the best of my >>> knowledge the only ones doing namespaces. Cgroups, OTOH, got a lot bigger. >>> >>> What I am mostly concerned about now, is how consistent they will be. >>> /proc always being always global indee…
creator: Glauber Costa
date: 2011-12-12T07:06:34-00:00

Re: How to draw values for /proc/stat
type: item
description: On 12/12/2011 11:06 AM, Glauber Costa wrote: > On 12/12/2011 04:31 AM, KAMEZAWA Hiroyuki wrote: >> On Sun, 11 Dec 2011 15:50:56 +0100 >> Glauber Costa<glommer@parallels.com> wrote: >> >>> On 12/09/2011 03:55 PM, Glauber Costa wrote: >>>> On 12/09/2011 12:03 PM, Peter Zijlstra wrote: >>>>> On Mon, 2011-12-05 at 07:32 -0200, Glauber Costa wrote: >>>>>> Hi, >>>>>> >>>>>> Specially Peter and Paul, but all the others: >>>>>> >>>>>> As you can see in https://lkml.org/lkml/2011/12/4/178, and in my >>>>>> answer >>>>>> to that, there is a question - one I've asked before but without that >>>>>> much of an audience - of whether /proc files read from process >>>>>> living on >>>>>> cgroups should display global or per-cgroup resources. >>>>>> >>>>>> In the past, I was arguing for a knob to control that, but I recently >>>>>> started to believe that a knob here will only overcomplicate matters: >>>>>> if you live in a cgroup, you should display only the resources you >>>>>> can >>>>>> possibly use. Global is for whoever is in the main cgroup. >>>>>> >>>>>> Now, it comes two questions: >>>>>> 1) Do you agree with that, for files like /proc/stat ? I think the >>>>>> most >>>>>> important part is to be consistent inside the system, regardless >>>>>> of what >>>>>> is done >>>>> >>>>> Personally I don't give a rats arse about (/proc vs) cgroups :-) >>>>> Currently /proc is unaffected by whatever cgroup you happen to be >>>>> in and >>>>> that seems to make some sort of sense. >>>>> >>>>> Namespaces seem to be about limiting visibility, cgroups about >>>>> controlling resources. >>>>> >>>>> The two things are hopelessly disjoint atm, but I believe someone was >>>>> looking at this mess. >>>> >>>> I did take a look at this (if anyone else was, I'd like to know so we >>>> can share some ideas), but I am not convinced we should do anything to >>>> join them anymore. We virtualization people are to the best of my >>>> knowledge the only ones doing namespaces. Cgroups, OTOH, got a lot >…
creator: Glauber Costa
date: 2011-12-12T08:22:25-00:00

Re: How to draw values for /proc/stat
type: item
description: On Fri, 2011-12-09 at 12:55 -0200, Glauber Costa wrote: > On 12/09/2011 12:03 PM, Peter Zijlstra wrote: > > Namespaces seem to be about limiting visibility, cgroups about > > controlling resources. > > > > The two things are hopelessly disjoint atm, but I believe someone was > > looking at this mess. > > I did take a look at this (if anyone else was, I'd like to know so we > can share some ideas), but I am not convinced we should do anything to > join them anymore. We virtualization people are to the best of my > knowledge the only ones doing namespaces. Cgroups, OTOH, got a lot bigger. > > What I am mostly concerned about now, is how consistent they will be. > /proc always being always global indeed does make sense, but my question > still stands: if you live in a resource-controlled world, why should you > even see resources you will never own ? Since without namespaces you can still see the rest of the world. So it makes sense to me to still see all resources too. Also, proportional controllers might not see a consistent slice of the resource, making the stats rather awkward to interpret. Furthermore, not everybody might care about these statistics at all and I know pjt objected to being subjected to the extra accounting (pjt do speak up etc..). > If it is not co-mounted, we draw the global value. If you don't mount > it, I someone does not mount it, I can assure you he doesn't care about > it. We for sure will. Anyway, looking at the rest of the emails in this thread the current proposal is a cgroup mount option that indicates if you want these per-cgroup stats or not, right?
creator: Peter Zijlstra
date: 2011-12-12T09:33:33-00:00

Re: How to draw values for /proc/stat
type: item
description: On 12/12/2011 01:33 PM, Peter Zijlstra wrote: > On Fri, 2011-12-09 at 12:55 -0200, Glauber Costa wrote: >> On 12/09/2011 12:03 PM, Peter Zijlstra wrote: > >>> Namespaces seem to be about limiting visibility, cgroups about >>> controlling resources. >>> >>> The two things are hopelessly disjoint atm, but I believe someone was >>> looking at this mess. >> >> I did take a look at this (if anyone else was, I'd like to know so we >> can share some ideas), but I am not convinced we should do anything to >> join them anymore. We virtualization people are to the best of my >> knowledge the only ones doing namespaces. Cgroups, OTOH, got a lot bigger. >> >> What I am mostly concerned about now, is how consistent they will be. >> /proc always being always global indeed does make sense, but my question >> still stands: if you live in a resource-controlled world, why should you >> even see resources you will never own ? > > Since without namespaces you can still see the rest of the world. So it > makes sense to me to still see all resources too. > > Also, proportional controllers might not see a consistent slice of the > resource, making the stats rather awkward to interpret. > > Furthermore, not everybody might care about these statistics at all and > I know pjt objected to being subjected to the extra accounting (pjt do > speak up etc..). > >> If it is not co-mounted, we draw the global value. If you don't mount >> it, I someone does not mount it, I can assure you he doesn't care about >> it. We for sure will. > > Anyway, looking at the rest of the emails in this thread the current > proposal is a cgroup mount option that indicates if you want these > per-cgroup stats or not, right? Well, it is something in this direction. I don't think it's entirely clear what exactly it will look like, but it seems we're making progress.
creator: Glauber Costa
date: 2011-12-12T09:35:09-00:00