From: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: KAMEZAWA Hiroyuki
<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org,
lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org,
daniel.lezcano-GANU6spQydw@public.gmane.org,
a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org,
jbottomley-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org,
pjt-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 0/4] Provide cpuacct functionality in cpu cgroup
Date: Wed, 23 Nov 2011 08:29:49 -0200 [thread overview]
Message-ID: <4ECCCB1D.2090501@parallels.com> (raw)
In-Reply-To: <20111116095706.6304e695.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
On 11/15/2011 10:57 PM, KAMEZAWA Hiroyuki wrote:
> On Tue, 15 Nov 2011 13:59:13 -0200
> Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
>
>> Hi,
>>
>> This is an excerpt of the last patches I sent regarding cpu cgroup.
>> It is mostly focused on cleaning up what we have now, so it can
>> be considered largely preparation. As a user of the new organization
>> of things, I am including cpuacct stats functionality in the end of
>> the series. The files related to cpuusage are left to be sent in
>> an upcoming series after this one is included.
>>
>> Let me know if there is anything you'd like me to address.
>>
>
> I'm sorry but let me several questions.
>
> Why cpu cgroup but cpuacct cgroup ?
> If scheduler stat is reported via cpu cgroup, it makes sense.
> If user accounting information is reported via cpu cgroup, I feel it's strange.
> Do you want to make cpuacct cgroup obsolete and merge 2 cgroups ?
>
> What's relationship between this new counters and cpuacct cgroup ?
> Aren't users confused ?
>
> Please provide Documenation.
Hi Kame,
Just so you know, I intend to withdraw this. This idea came from a
discussion with Peter, where we were thinking about ways to avoid
collecting statistics more than once, and walking structures more than
once as well (And cpuusage, for instance, was already collected for the
task_groups in the scheduler).
Now, Balbir pointed out that the use case for this really needs to keep
the statistics orthogonal to scheduler entities. So with that in mind,
merging them would complicate things more than it would simplify.
I think I can go back to my original version, where /proc/stat data is
shown according to data collected in cpuacct.
--
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: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: <linux-kernel@vger.kernel.org>, <paul@paulmenage.org>,
<lizf@cn.fujitsu.com>, <daniel.lezcano@free.fr>,
<a.p.zijlstra@chello.nl>, <jbottomley@parallels.com>,
<pjt@google.com>, <cgroups@vger.kernel.org>
Subject: Re: [PATCH 0/4] Provide cpuacct functionality in cpu cgroup
Date: Wed, 23 Nov 2011 08:29:49 -0200 [thread overview]
Message-ID: <4ECCCB1D.2090501@parallels.com> (raw)
In-Reply-To: <20111116095706.6304e695.kamezawa.hiroyu@jp.fujitsu.com>
On 11/15/2011 10:57 PM, KAMEZAWA Hiroyuki wrote:
> On Tue, 15 Nov 2011 13:59:13 -0200
> Glauber Costa<glommer@parallels.com> wrote:
>
>> Hi,
>>
>> This is an excerpt of the last patches I sent regarding cpu cgroup.
>> It is mostly focused on cleaning up what we have now, so it can
>> be considered largely preparation. As a user of the new organization
>> of things, I am including cpuacct stats functionality in the end of
>> the series. The files related to cpuusage are left to be sent in
>> an upcoming series after this one is included.
>>
>> Let me know if there is anything you'd like me to address.
>>
>
> I'm sorry but let me several questions.
>
> Why cpu cgroup but cpuacct cgroup ?
> If scheduler stat is reported via cpu cgroup, it makes sense.
> If user accounting information is reported via cpu cgroup, I feel it's strange.
> Do you want to make cpuacct cgroup obsolete and merge 2 cgroups ?
>
> What's relationship between this new counters and cpuacct cgroup ?
> Aren't users confused ?
>
> Please provide Documenation.
Hi Kame,
Just so you know, I intend to withdraw this. This idea came from a
discussion with Peter, where we were thinking about ways to avoid
collecting statistics more than once, and walking structures more than
once as well (And cpuusage, for instance, was already collected for the
task_groups in the scheduler).
Now, Balbir pointed out that the use case for this really needs to keep
the statistics orthogonal to scheduler entities. So with that in mind,
merging them would complicate things more than it would simplify.
I think I can go back to my original version, where /proc/stat data is
shown according to data collected in cpuacct.
next prev parent reply other threads:[~2011-11-23 10:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-15 15:59 [PATCH 0/4] Provide cpuacct functionality in cpu cgroup Glauber Costa
2011-11-15 15:59 ` [PATCH 1/4] Change cpustat fields to an array Glauber Costa
2011-11-16 5:58 ` Paul Turner
2011-11-16 11:25 ` Glauber Costa
2011-11-16 11:31 ` Glauber Costa
2011-11-15 15:59 ` [PATCH 2/4] split kernel stat in two Glauber Costa
2011-11-16 6:12 ` Paul Turner
2011-11-16 11:34 ` Glauber Costa
2011-11-15 15:59 ` [PATCH 3/4] Keep scheduler statistics per cgroup Glauber Costa
2011-11-16 7:02 ` Paul Turner
2011-11-16 11:56 ` Glauber Costa
2011-11-15 15:59 ` [PATCH 4/4] provide a version of cpuacct statistics inside cpu cgroup Glauber Costa
[not found] ` <1321372757-1581-5-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-11-17 7:12 ` Balbir Singh
2011-11-17 7:12 ` Balbir Singh
2011-11-16 0:57 ` [PATCH 0/4] Provide cpuacct functionality in " KAMEZAWA Hiroyuki
[not found] ` <20111116095706.6304e695.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2011-11-23 10:29 ` Glauber Costa [this message]
2011-11-23 10:29 ` 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=4ECCCB1D.2090501@parallels.com \
--to=glommer-bzqdu9zft3wakbo8gow8eq@public.gmane.org \
--cc=a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=daniel.lezcano-GANU6spQydw@public.gmane.org \
--cc=jbottomley-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
--cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org \
--cc=paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org \
--cc=pjt-hpIqsD4AKlfQT0dZR+AlfA@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.