Power Efficiency (was Re: Leaving the Desktop Market)

[Jordan Hubbard]

On Apr 3, 2014, at 7:50 PM, Alan Somers <asomers at freebsd.org> wrote:

> Instead of reinventing the wheel, how about porting powertop to
> FreeBSD?  It's already got several output modes, and it's designed to
> monitor the same kind of hardware that FreeBSD users have.  The only
> downside is that it relies on Linux's sysfs, and possibly some other
> Linux-specific APIs as well.  Still, I think it would be easier for us
> to add a few sysctls and port powertop to use a sysctl interface than
> it would be to rewrite everything from scratch.

I don’t think this is re-inventing the wheel as much as you might think, and here’s why:

1. A comprehensive monitoring framework, such as I described, does a lot more than tell you that a device or a process is using X joules of power.  That kind of information just by itself is actually not particularly useful, since it doesn’t tell you where specifically in the code that power is actually being consumed or what external events to correlate against it (the code itself may be innocuous but only become pathological in the presence of other factors).

To use a microscope analogy, what powertop gives you is essentially the lowest magnification factor.  It’s nice for the first level of “hmmm, that’s weird!” deduction, but then you'll immediately want to “zoom in” and figure out what parts of the code are actually hot and/or what kernel services are being called the most often by the offending process or device driver, at which point you'll then want to zoom in again on that part of the kernel to see what it’s doing.

That’s why you really want to think of the telemetry problem from the bottom up.  A tool like top(1) (or Activity Monitor, if you want to get all graphical about it) is, no pun intended, at the top of the stack.  It’s where the highest level of summarization takes place, but all the data it uses also needs to be readily available to the various analysis tools which will actually ultimately lead you to one or more lines of code that need changing, an exercise that often isn’t as straight-forward as looking at raw profiling counters but requires a fair amount of cross-correlation between seemingly unrelated activities.

2.  If you look at the powertop code (and I have - version 2.5 to be specific) you’ll quickly see that there’s really not much there.  It’s leveraging a lot of work that’s already been done in the linux kernel to provide the interrupt/timer/wakeup statistics and the device-specific information, work which would all need to be re-implimented (or impedance matched to powertop) in FreeBSD’s own kernel.  The resulting powertop code base would bear so little resemblance to the linux original you would have indeed reinvented the wheel almost entirely at the end, and suffered the consequences of starting with someone else’s specs for a wheel rather than your own.

In any case, even if powertop had already been ported to FreeBSD and was running with full functionality, I would still want to start with a thorough examination of the problem and what kinds of telemetry data we wanted rather than coming straight at this with an existing solution and trying to, in effect, short-circuit the whole analysis phase first.  That’s usually a bad idea, and I don’t think we’ve examined the problem we want to solve in enough detail to be casting around for solutions just yet.  We’ll have plenty of time for that later, once we’re all sure we’re on the same page about what we want.  Believe me, I’ve been through this whole exercise once before (for both mobile and desktop devices) and it’s nowhere near as straight-forward as it first seems!

- Jordan