linux-kernel - Re: [PATCH 05/10] Make total

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E958F1B.80605@parallels.com>
Date:	Wed, 12 Oct 2011 16:59:07 +0400
From:	Glauber Costa <glommer@...allels.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
CC:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	<linux-kernel@...r.kernel.org>, <paul@...lmenage.org>,
	<lizf@...fujitsu.com>, <daniel.lezcano@...e.fr>,
	<jbottomley@...allels.com>
Subject: Re: [PATCH 05/10] Make total_forks per-cgroup

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/