linux-kernel - Re: [PATCH v2 14/14] Change CPUACCT to default n

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPM31RLcUUzCXqfrALgAc0g_A0uOq-Htaz50vcpqoo83Nc0tpA@mail.gmail.com>
Date:	Sat, 26 Nov 2011 05:18:02 -0800
From:	Paul Turner <pjt@...gle.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Balbir Singh <bsingharora@...il.com>,
	Glauber Costa <glommer@...allels.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux-kernel@...r.kernel.org, paul@...lmenage.org,
	lizf@...fujitsu.com, daniel.lezcano@...e.fr,
	jbottomley@...allels.com, fweisbec@...il.com
Subject: Re: [PATCH v2 14/14] Change CPUACCT to default n

On Fri, Nov 25, 2011 at 2:19 AM, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> On Fri, 2011-11-25 at 11:08 +0530, Balbir Singh wrote:
>> It is not about $customer. I am OK with a design that allows
>> accounting independent of control. Put it another way when I look at
>> cgroups, I see the following functionality
>>
>> 1. Accounting and feedback
>> 2. Control
>>
>> Why do 1 and 2 have to co-exist. A good case would be that we might
>> need just stats and might want to implement control based on 1.
>
> I would say that 2 always requires 1 (provided they are of course on the
> same subject), for the very simple reason that you need to know the
> current state (as provided by 1) to control it (2).
>
> Therefore separating them leads to useless duplication.

Almost all of the stats that are coming in here are completely useless
for control and don't belong in the cpu controller.

While it's not as pure we really have 2 tiers of statistic:

1) Accounting needed for control
2) Everything else

What causes so much over-head for cpuacct currently is that it tries
to maintain a separate accounting of usage.  If this were removed from
the controller then it would be *much* cheaper, even with all extra
stats added here.

This series adds a lot of statistics in the second category, they
really have no common touch points on the cpu controller path.  That
second category could be re-worded as 'accounting how scheduled time
is spent' as opposed to the actual accounting of scheduling decisions.
 I would really rather not see anything in that category weighing down
the cpu-controller any more than it already is.

- Paul
>
>> But if
>> I have to do both 1 and 2 together, how do we decide on control
>> values?
>
> Uh, what?
>
> What was not answered is, is there a sane reason to have both on
> different hierarchies? I think the whole different hierarchy per
> controller thing is one of the biggest trainwrecks of cgroups.
>
> It allows for great confusion, but I haven't yet seen an up-side to it.
>
--
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/