Re: [PATCH 05/10] Make total_forks per-cgroup

[Glauber Costa <glommer@parallels.com>]

On 10/12/2011 05:03 PM, Frederic Weisbecker wrote:
> On Wed, Oct 12, 2011 at 04:59:07PM +0400, Glauber Costa wrote:
>> 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.
>
> But only to the first parent or also all ancestors?
it keeps going until it reaches the root task group.