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

[Frederic Weisbecker <fweisbec@gmail.com>]

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?