linux-kernel - Re: [RFD 0/9] per-cgroup /proc/stat statistics

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]

Date:	Wed, 28 Sep 2011 00:11:53 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Glauber Costa <glommer@...allels.com>
Cc:	linux-kernel@...r.kernel.org, paul@...lmenage.org,
	lizf@...fujitsu.com, daniel.lezcano@...e.fr,
	jbottomley@...allels.com
Subject: Re: [RFD 0/9] per-cgroup /proc/stat statistics

On Fri, 2011-09-23 at 19:20 -0300, Glauber Costa wrote:
> Hi,
> 
> Since I've sent already a RFC about it, I am sending now a RFD.
> If you eager for meaning, this can then be a "Request for Doctors",
> since Peter is likely to have a heart attack now.

:-)

All we need is to ensure the case of cgroups enabled but not used isn't
actually more expensive that what we have now, after that, if people
create a 100 deep cgroup hierarchy they get what they asked.

>From a conceptual pov this patch-set is a lot saner than the previous
one, doesn't duplicate nearly as much and actually tries to improve the
code (although I suspect simply killing off cputime64_t as a whole will
get us even more).

> So here's the deal:
> 
> * My main goal here was to demonstrate that we can avoid double accounting
>   in a lot of places. So what I did was getting rid of the original and first
>   kstat mechanism, and use only cgroups accounting for that. Since the parent
>   is always updated, the original stats are the one for the root cgroup.

Right, current patch-set won't compile for those who have CGROUP=n
kernels though, need to find something for that. Shouldn't be too hard
though. It looks like you only need to provide static per-cpu storage
and a custom version of task_cgroup_account_field().

> * I believe that all those cpu cgroups are confusing and should be unified. Not
>   that we can simply get rid of it, but my goal here is to provide all the
>   information they do, in cpu cgroup. If the set of tasks needed for accounting
>   is not independent of the ones in cpu cgroup, we can avoid double accounting
>   for that. I default cpuacct to n, but leave it to people that wants to use it
>   alone. 

Amen! Ideally we place cpuacct on the deprecated list or somesuch..

> * Well, I'm also doing what I was doing originally: Providing a per-cgroup version
>   of the /proc/stat file.

Right, so how much sense does it make to keep calling it proc.stat?
--
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/