Re: [gentoo-user] [OT] Calculating power consumption of a running program?

[R0b0t1]

On Wed, Aug 23, 2017 at 5:49 PM, Alan McKinnon <alan.mckinnon@×××××.com> wrote:
> On 24/08/2017 00:29, R0b0t1 wrote:
>> As an example, I am interested in characterizing the power consumption
>> of rendering a PDF document. I would hopefully only need to run the
>> renderer once.
>>
>> I can use PowerTOP, but it seems to be limited to rough measurements
>> on the order of tenths of a watt. This measurement can be divided
>> among the wakeup events in an attempt to calculate software power
>> consumption but it seems imperfect if I want to monitor a single
>> process that may be competing relatively equally for resources with
>> the kernel and other user processes.
>>
>> PMBus is a spinoff of SMBus which is a spinoff of I2C which is found
>> on many motherboards. PMBus is supposed to be the interface which
>> controls and reports power supply activity. Besides the main kW power
>> supply, there is usually a power supply near your processor that steps
>> down 3.3V or 5V to 2.8V, 1.8V, or lower (I've seen as low as 0.8V, but
>> not on a desktop). I was not aware these had a visible interface.
>>
>> Apparently you can talk to these, but my searches can only find code
>> which seems highly experimental. The other replies seem to be for
>> embedded Linux systems running on FPGAs and perhaps Cortex-A parts.
>>
>> If I were using a microcontroller I could get uA or nA draw per MHz
>> and I know my operating voltage and operating time. However, desktop
>> processors are much more complex, and I am not sure if they have been
>> entirely characterized. The most advanced tool I can find is PowerTOP
>> and it does not seem very accurate.
>>
>> Does anyone have any suggestions? Should I start reading source code
>> or post on the forums?
>
> Both of these sound good
>
>> Or perhaps someone has used PowerTOP and found
>> it to be reasonably accurate?
>
> No not this. PowerTOP was designed to find badly-behaving programs like
> pidgin that woke up and polled it's queue every 1ms or so. It's not for
> what you want at all, not even close.
>

That's kind of unfortunate. It's the only software I was able to find.
There's another program, LatencyTOP, that might use API that is
relevant for my purposes (interruptible states are important for power
management), but it looks like development on it has stalled.


PoisonBL, I think my response to Alec touches on some of your points as well.

On Wed, Aug 23, 2017 at 8:39 PM, Alec Ten Harmsel
<alec@××××××××××××××.com> wrote:
> On Wed, Aug 23, 2017 at 05:29:13PM -0500, R0b0t1 wrote:
>> As an example, I am interested in characterizing the power consumption
>> of rendering a PDF document. I would hopefully only need to run the
>> renderer once.
>
> I remember in college some interesting work in security-related stuff
> that was about characterizing power draw in order to crack passwords.
> Potentially that could be useful, as you could record the waveforms
> going into your power supply while rendering a PDF, but it sure sounds
> complicated.
>

That is an additional application. It's actually amazing how course
the information needed is - it was possible to listen to a switch mode
power supply's audible frequencies to recover the (asymmetric?) key
being used to encrypt data.

>> Apparently you can talk to these, but my searches can only find code
>> which seems highly experimental. The other replies seem to be for
>> embedded Linux systems running on FPGAs and perhaps Cortex-A parts.
>
> Even if you could talk to these, taking periodic measurements of
> current and voltage, then integrating over time would probably give
> results with large errors.
>

Right. However as above, my situation is a poor one, any information
is better than what I am looking at now. There are embedded (ranging
up to Cortex-A parts) boards that have very detailed power reporting
capabilities, but it adds a noticeable amount to the bill of
materials. If I am lucky the drive for lower power consumption in
laptops and desktops means these things exists in those products. I am
not sure I can access them if they do, power management in Linux still
lags behind proprietary OSes, unfortunately.

I am hoping they offer data streaming or the ability to set maximum
power output. If I can cap the power output I could compare
performance between two setpoints, although this suffers from a lot of
variability as well.

I'm not sure I can get data on or from any regulators that exist
inside the processor, or any power management facilities that are on
the processor die (a popular setup is to control a buck/boost
converter directly from the processor, as in it is integrated directly
with the processor's power management facilities; modern processors
likely have much more than that). If I could do that, that would give
me the best data I might be able to get.

>> If I were using a microcontroller I could get uA or nA draw per MHz
>> and I know my operating voltage and operating time. However, desktop
>> processors are much more complex, and I am not sure if they have been
>> entirely characterized. The most advanced tool I can find is PowerTOP
>> and it does not seem very accurate.
>
> Due to modern processors having things like pipelines and all of the
> caching and memory pre-fetching going on behind the scenes, it's probably
> not easy to measure this with any degree of accuracy.
>

This are things I am hoping to instrument as well. I think some of the
rationale behind PowerTOP is that cstates and other interruptible
states are the best way to measure power consumption. Those events
likely drive all IO access, and some of those wake ups are due to IO
request completion events. E.g. most of what the processor should be
doing is sleeping, and it makes sense to only know when it's awake.

It's possible I might be able to use the API that PowerTOP uses to get
far better power draw estimates, but unfortunately, those would still
be estimates. I might also be able to use information from the
scheduler. I am not sure how to get estimates for power usage at the
lowest level, like microwatt per MHz per core, or more advanced
estimates involving memory controllers.

> Have fun,
>
> Alec
>

I hope it is fun. I may not be smart enough to have fun doing this.

R0b0t1.