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] [day] [month] [year] [list]
Date:	Wed, 12 Oct 2011 16:03:14 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Glauber Costa <glommer@...allels.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 Wed, Oct 12, 2011 at 05:03:52PM +0400, Glauber Costa wrote:
> 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:
> >>>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.

Using the task counter subsystem for that would involve
a bit more complications like adding a new counter on it
that would need to be incremented in parallel but differently.
You would also need to bind this subsystem anytime you
want this statistic.

I don't think it's worth doing this. You would also get the
overhead in the exit path because the subsystem also uncharge
one of its counters across the whole hierarchy.

OTOH, it's scary to see that new feature will walk
the entire hierarchy on every fork when CONFIG_CGROUP_SCHED=y
And I guess that today this config is easily selected by
distros.

IIUC that walk also happen on every timer interrupt for
the user/system/idle cpu time accounting?

May be this should reside in a seperate config, so that those
that don't care about the per cgroup stats avoid that
overhead?
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ