Date: Thu, 3 Apr 2014 08:50:06 -0600 From: Alan Somers <asomers@freebsd.org> To: Jordan Hubbard <jkh@ixsystems.com> Cc: Alexey Dokuchaev <danfe@nsu.ru>, "freebsd-hackers@freebsd.org" <hackers@freebsd.org>, David Chisnall <theraven@freebsd.org>, Eitan Adler <lists@eitanadler.com> Subject: Re: Power Efficiency (was Re: Leaving the Desktop Market) Message-ID: <CAOtMX2gwyEYM4DthpvRO3D=BmpTNnVH-tOgiMKxC=iRr=kS6Ug@mail.gmail.com> In-Reply-To: <89A553DC-199A-47E3-B352-34A4CDCAC4E4@ixsystems.com> References: <CAF6rxgkeBozvfV-L0%2BrFZ6fWRn0=Gi3BNq1kPL=-HTq0TD6MkQ@mail.gmail.com> <A70900DF-4BAA-427F-8731-01211FFD1887@mail.turbofuzz.com> <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140403034150.GA78653@regency.nsu.ru> <89A553DC-199A-47E3-B352-34A4CDCAC4E4@ixsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 2, 2014 at 11:45 PM, Jordan Hubbard <jkh@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@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, opportunit= ies >>> for improvement. The Symbian EKA2 book has some very interesting detai= l on >>> their power management infrastructure, which would be worth looking at = for >>> anyone interested in working on this, and I believe your former employe= r >>> had some expertise in this area. >> >> Now that's something I'm glad to hear. It would be cool if FreeBSD gain= ed >> 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 mo= bile / "internet of things" roles (and if you read that Ars Technical artic= le I cited earlier, one particular quote, with which I heartily agree, was:= "I think the desktop on its own will die," Shuttleworth said, explaining t= hat 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 digit= al hub (to use Apple's marketing parlance) into which you plug sources of d= ata, manage that data, mash it up in new and different ways, etc. on its wa= y to somewhere else. It's most important as a command-and-control or midwa= y point for other devices, in other words, and if it's not designed to inte= roperate with those devices and instead wants to assume that it's really th= e first class citizen in the equation, then that desktop is marked for deat= h. :) > > 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. An= y OS X user is probably familiar with the "systemstats" command, though wha= t they probably aren't as conscious of is just how far and wide (or deep) t= he instrumentation has to go to produce the information you see summarized = there. What's also not apparent is just how valuable that sort of informat= ion is in determining where the majority of your work lies, or how effectiv= e 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 t= o 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 som= etimes even made things worse. > > I would therefore propose this as the first and most obvious place to sta= rt. Pick an efficient and concise "logging" format (though this isn't logg= ing - this is more like auditing) and design an API that works in both kern= el 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) i= s going to exhibit all the behaviors you want to capture. In fact, the mor= e machines you can collect this data from, the better. With suitable anony= mization, I can see this being something a lot of FreeBSD users would be fi= ne with opting into, and even if the project itself doesn't want to get int= o the data collection business, various appliance vendors with smaller and = more focused ecosystems would certainly be interested and could leverage th= e same technology to set up their own telemetry collection points. We'd us= e it! > > As long as the user has the option of opting in explicitly, I don't see a= ny downside as long as the data collection process itself doesn't cause dis= ruption of service or end up penalizing power or performance (which would b= e 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 im= pact. This is also why existing mechanisms like dtrace / ktrace / truss ar= e simply not suitable. They are fairly blunt instruments which are excelle= nt "swiss army knife" tools for applying in a broad variety of scenarios, b= ut they're not meant to be used all the time, and if you really want to col= lect data that will capture those specific moments when things run amuck or= otherwise exhibit pathological behavior when you're not watching (which Mu= rphy's law practically dictates will happen *especially* when you're not wa= tching), then the data collection needs to happen all the time. > > And yes, this is important enough to us that we'd be willing to contribut= e 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= "
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2gwyEYM4DthpvRO3D=BmpTNnVH-tOgiMKxC=iRr=kS6Ug>