From: Glauber Costa <glommer@parallels.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
<linux-kernel@vger.kernel.org>, <paul@paulmenage.org>,
<lizf@cn.fujitsu.com>, <daniel.lezcano@free.fr>,
<jbottomley@parallels.com>
Subject: Re: [PATCH 05/10] Make total_forks per-cgroup
Date: Wed, 12 Oct 2011 16:59:07 +0400 [thread overview]
Message-ID: <4E958F1B.80605@parallels.com> (raw)
In-Reply-To: <20111012125857.GE14968@somewhere>
On 10/12/2011 04:59 PM, Frederic Weisbecker wrote:
> On Wed, Oct 12, 2011 at 11:35:50AM +0400, Glauber Costa wrote:
>> On 10/12/2011 03:45 AM, Frederic Weisbecker wrote:
>>> On Wed, Oct 05, 2011 at 04:12:00PM +0400, Glauber Costa wrote:
>>>> On 10/05/2011 01:05 PM, Peter Zijlstra wrote:
>>>>> On Sun, 2011-10-02 at 23:21 +0400, Glauber Costa wrote:
>>>>>> This patch counts the total number of forks per-cgroup.
>>>>>> The information is propagated to the parent, so the total
>>>>>> number of forks in the system, is the parent cgroup's one.
>>>>>>
>>>>>> To achieve that, total_forks is made per-cpu. There is no
>>>>>> particular reason to do that, but by doing this, we are
>>>>>> able to bundle it inside the cpustat structure already
>>>>>> present.
>>>>>
>>>>> I think fweisbec is also doing something with forks and cgroups.
>>>>
>>>> I am all ears...
>>>>
>>>> Frederic, does it conflict with what you're doing ?
>>>
>>> I don't know if that really conflicts but I'm working
>>> on a cgroup subsystem that is able to control the number
>>> of tasks running in a subsystem.
>>>
>>> It consists in two new files added:
>>>
>>> * tasks.usage
>>> * tasks.limit
>>>
>>> The subsystem rejects any new fork or migration into the
>>> cgroup when tasks.usage> tasks.limit
>>>
>>> So tasks.usage can inform you about the number of tasks
>>> running into the cgroup. It's not strictly the number
>>> of forks because it also counts the tasks that have been
>>> attached to the cgroup.
>>>
>>> But something like a tasks.fork file could be implemented
>>> in that subsystem as well.
>>>
>>> It depends on what you need.
>>
>> So the specific piece I am working on, is to display /proc/stat
>> information per-cgroup. One of the many fields it has, is
>> total_forks.
>> (it is actually just a small part of the series)
>> So instead of tracking how many forks the system has in total, I'll
>> track it per-cpucgroup.
>>
>> So I don't think we conflict at all. At the very least, IIUC, you
>> are planning to account and check *before* a fork happens, right?
>> This particular stat is incremented after it already succeeded.
>
> That doesn't make much difference since the accounting is cancelled
> in case the fork is finally rejected.
>
> But probably having a simple accouting like you do involves less
> overhead than the whole task counter subsystem.
>
> Is your counting propagated to the parents in a hierarchy?
> For example if A is parent cgroup of B and C, does A account the
> forks happening in B and C?
Yes.
next prev parent reply other threads:[~2011-10-12 12:59 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-02 19:21 [PATCH 00/10] Per-cgroup /proc/stat information Glauber Costa
2011-10-02 19:21 ` [PATCH 01/10] trivial: initialize root cgroup's sibling list Glauber Costa
2011-10-02 19:21 ` [PATCH 02/10] Change cpustat fields to an array Glauber Costa
2011-10-02 19:21 ` [PATCH 03/10] Move /proc/stat logic inside sched.c Glauber Costa
2011-10-02 19:21 ` [PATCH 04/10] Display /proc/stat information per cgroup Glauber Costa
2011-10-05 8:56 ` Peter Zijlstra
2011-10-05 12:10 ` Glauber Costa
2011-10-05 12:38 ` Peter Zijlstra
2011-10-05 12:43 ` Glauber Costa
2011-10-05 9:04 ` Peter Zijlstra
2011-10-05 12:11 ` Glauber Costa
2011-10-02 19:21 ` [PATCH 05/10] Make total_forks per-cgroup Glauber Costa
2011-10-05 9:05 ` Peter Zijlstra
2011-10-05 12:12 ` Glauber Costa
2011-10-11 23:45 ` Frederic Weisbecker
2011-10-12 7:35 ` Glauber Costa
2011-10-12 12:59 ` Frederic Weisbecker
2011-10-12 12:59 ` Glauber Costa [this message]
2011-10-12 13:03 ` Frederic Weisbecker
2011-10-12 13:03 ` Glauber Costa
2011-10-12 14:03 ` Frederic Weisbecker
2011-10-02 19:21 ` [PATCH 06/10] per-cgroup boot time Glauber Costa
2011-10-02 19:21 ` [PATCH 07/10] Report steal time for cgroup Glauber Costa
2011-10-02 19:21 ` [PATCH 08/10] provide a version of cpuacct statistics inside cpu cgroup Glauber Costa
2011-10-05 9:10 ` Peter Zijlstra
2011-10-05 12:16 ` Glauber Costa
2011-10-02 19:21 ` [PATCH 09/10] provide a version of cpuusage " Glauber Costa
2011-10-05 9:14 ` Peter Zijlstra
2011-10-05 12:17 ` Glauber Costa
2011-10-05 9:46 ` Peter Zijlstra
2011-10-05 12:22 ` Glauber Costa
2011-10-05 12:31 ` Peter Zijlstra
2011-10-05 15:05 ` Glauber Costa
2011-10-02 19:21 ` [PATCH 10/10] Change CPUACCT to default n 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=4E958F1B.80605@parallels.com \
--to=glommer@parallels.com \
--cc=a.p.zijlstra@chello.nl \
--cc=daniel.lezcano@free.fr \
--cc=fweisbec@gmail.com \
--cc=jbottomley@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=paul@paulmenage.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox