Power Efficiency (was Re: Leaving the Desktop Market)

[Alan Somers]

On Wed, Apr 2, 2014 at 11:45 PM, Jordan Hubbard <jkh at ixsystems.com> wrote:
> [ Dropping Advocacy and Current from the CC as this has morphed ]
>
> On Apr 3, 2014, at 8:41 AM, Alexey Dokuchaev <danfe at nsu.ru> wrote:
>
>>> Some things have already seen progress, for example Davide's calloutng work
>>> includes timer coalescing, but there are still a lot of, uh, opportunities
>>> for improvement.  The Symbian EKA2 book has some very interesting detail on
>>> their power management infrastructure, which would be worth looking at for
>>> anyone interested in working on this, and I believe your former employer
>>> had some expertise in this area.
>>
>> Now that's something I'm glad to hear.  It would be cool if FreeBSD gained
>> some power-efficient software that run smoothly together with hardware (and
>> laptops in particular) developed by Jordan's former employer. ;-)
>
> I'm also glad to hear that, especially as it will have a big impact on mobile / "internet of things" roles (and if you read that Ars Technical article I cited earlier, one particular quote, with which I heartily agree, was: "I think the desktop on its own will die," Shuttleworth said, explaining that it must be paired with mobile success to embrace the shifting nature of personal computing.").
>
> A desktop (increasingly redefined to "laptop") is ultimately just a digital hub (to use Apple's marketing parlance) into which you plug sources of data, manage that data, mash it up in new and different ways, etc. on its way to somewhere else.  It's most important as a command-and-control or midway point for other devices, in other words, and if it's not designed to interoperate with those devices and instead wants to assume that it's really the first class citizen in the equation, then that desktop is marked for death. :)
>
> Back to power, however, since that's the subject:  I would first ask the core team / foundation about their plans for the measurement side of things, without which there is really no power management effort since you can't optimize power or performance based purely on guesses and speculation.   Any OS X user is probably familiar with the "systemstats" command, though what they probably aren't as conscious of is just how far and wide (or deep) the instrumentation has to go to produce the information you see summarized there.  What's also not apparent is just how valuable that sort of information is in determining where the majority of your work lies, or how effective your ongoing efforts to optimize power and performance are.  There are a lot of blind alleys in this kind of work, and without telemetry it's easy to fool yourself into thinking you've just pulled off a major coup when, in reality, all you've done is shaved off a few fractions of a percent, or sometimes even made things worse.
>
> I would therefore propose this as the first and most obvious place to start.  Pick an efficient and concise "logging" format (though this isn't logging - this is more like auditing) and design an API that works in both kernel and user land for allowing things to cut records and identify just where each record came from.  Write a tool for exporting that data to a central collection point periodically since no single machine (or usage scenario) is going to exhibit all the behaviors you want to capture.  In fact, the more machines you can collect this data from, the better.  With suitable anonymization, I can see this being something a lot of FreeBSD users would be fine with opting into, and even if the project itself doesn't want to get into the data collection business, various appliance vendors with smaller and more focused ecosystems would certainly be interested and could leverage the same technology to set up their own telemetry collection points.  We'd use it!
>
> As long as the user has the option of opting in explicitly, I don't see any downside as long as the data collection process itself doesn't cause disruption of service or end up penalizing power or performance (which would be both ironic and bad).  That's why you want to design a purpose-built data collection system that you can optimize for maximum utility and minimal impact.  This is also why existing mechanisms like dtrace / ktrace / truss are simply not suitable.  They are fairly blunt instruments which are excellent "swiss army knife" tools for applying in a broad variety of scenarios, but they're not meant to be used all the time, and if you really want to collect data that will capture those specific moments when things run amuck or otherwise exhibit pathological behavior when you're not watching (which Murphy's law practically dictates will happen *especially* when you're not watching), then the data collection needs to happen all the time.
>
> And yes, this is important enough to us that we'd be willing to contribute to the effort, not just talk about it on -hackers. ;-)

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.

https://github.com/fenrus75/powertop
https://01.org/powertop/

-Alan


>
> - Jordan
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"