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] [day] [month] [year] [list]

Message-ID: <CAKTCnz=Xk7fsvF6asN4v6m5ma4-B38a5+FGRNOmhr+ftGpxPmA@mail.gmail.com>
Date:	Mon, 28 Nov 2011 13:59:29 +0530
From:	Balbir Singh <bsingharora@...il.com>
To:	Paul Turner <pjt@...gle.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	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 Sat, Nov 26, 2011 at 6:48 PM, Paul Turner <pjt@...gle.com> wrote:
> 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.
>

Sure, if we can integrate the stats without control, I am all for it :)

Balbir Singh
--
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/