Messages in this thread | | | Date | Wed, 12 Oct 2011 16:59:07 +0400 | From | Glauber Costa <> | 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.
| |