Messages in this thread | | | Date | Wed, 12 Oct 2011 15:03:47 +0200 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 05/10] Make total_forks per-cgroup |
| |
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?
| |