linux-kernel - Re: [PATCH v2 0/3] Enable CPU frequency and power tracking in cpuacct cgroup

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]

Message-ID: <AANLkTilmHyf7XHiYY_U45s7W0yrwBkm2fFW1GfSL3kOT@mail.gmail.com>
Date:	Tue, 1 Jun 2010 13:56:33 -0700
From:	Mike Chan <mike@...roid.com>
To:	Kevin Hilman <khilman@...prootsystems.com>
Cc:	Thomas Renninger <trenn@...e.de>, menage@...gle.com,
	balbir@...ibm.com, cpufreq@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v2 0/3] Enable CPU frequency and power tracking in cpuacct 
	cgroup

On Fri, May 21, 2010 at 10:05 AM, Kevin Hilman
<khilman@...prootsystems.com> wrote:
> Mike Chan <mike@...roid.com> writes:
>
>> On Thu, May 20, 2010 at 2:01 PM, Thomas Renninger <trenn@...e.de> wrote:
>>> Hi Mike,
>>>
>>> On Thursday 20 May 2010 08:42:21 pm Mike Chan wrote:
>>>> v2:
>>>> Rebased off of Thomas Renninger's patch for cgroups_cpuacct refactoring,
>>> thanks.
>>> A general comment:
>>> I don't know much about the cgroup stuff.
>>
>> Perhaps Paul Menage or Balbir Singh can look and sign off on the API's?
>>
>>> I am also not sure how exactly power can be measured on this arch based on
>>
>> If you know how much time was spent at each frequency executing code,
>> you can calculate how much power was consumed if the platform (with
>> hooks) provide power numbers (in milliWatts) for the power at
>> frequency X.
>>
>> I did some initial testing on Motorola Droid comparing to a power
>> meter and I got within 2% variance.
>>
>>> frequency accounting (there also were some threads I was not aware of?)
>>> A signed-off-by or reviewed-by from someone who is more involved in this omap
>>> stuff would probably not that bad.
>>>
>>
>> OMAP was the closest with mainline support I could provide an example
>> how to use these hooks.
>>
>> I'm hoping for some blessing from some people on the linux-omap list
>> for that. However can we possibly just stack the first two patches to
>> get the API in? This will make it easier to fixup the omap hooks if
>> they don't get in.
>
> This looks like a great enhancement to me.
>
> Speaking for OMAP PM... I'd suggest getting the generic stuff upstream
> (or into -next) soon and then work out the OMAP specifics after.
>
> Since the OMAP OPP layer is going through some churn (but stabilizing
> and will be submitted for 2.6.36), I'd suggest we queue the
> OMAP-specific parts of this along with the OPP layer changes.
>

So it looks like there is no objections to this API and I'm OK with
dropping the omap hooks for now until things are settled in 2.6.36. So
are things good with Thomas' re-factoring patch for cpuacct as well as
the first 2 patches?

-- Mike

> Kevin
>
--
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/