Date: Thu, 3 Apr 2014 10:45:21 +0500 From: Jordan Hubbard <jkh@ixsystems.com> To: Alexey Dokuchaev <danfe@nsu.ru> Cc: Eitan Adler <lists@eitanadler.com>, hackers@FreeBSD.org, David Chisnall <theraven@FreeBSD.org> Subject: Power Efficiency (was Re: Leaving the Desktop Market) Message-ID: <89A553DC-199A-47E3-B352-34A4CDCAC4E4@ixsystems.com> In-Reply-To: <20140403034150.GA78653@regency.nsu.ru> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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, = 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. >=20 > 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=92m also glad to hear that, especially as it will have a big impact on = mobile / =93internet of things=94 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.=94). A desktop (increasingly redefined to =93laptop=94) is ultimately just a = digital hub (to use Apple=92s 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=92s most important as a = command-and-control or midway point for other devices, in other words, = and if it=92s not designed to interoperate with those devices and = instead wants to assume that it=92s really the first class citizen in = the equation, then that desktop is marked for death. :) Back to power, however, since that=92s 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=92t optimize power or performance based purely on guesses and = speculation. Any OS X user is probably familiar with the =93systemstats=94= command, though what they probably aren=92t 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=92s 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=92s easy to fool yourself = into thinking you=92ve just pulled off a major coup when, in reality, = all you=92ve 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 =93logging=94 format (though this = isn=92t 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=92t 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=92d = use it! As long as the user has the option of opting in explicitly, I don=92t = see any downside as long as the data collection process itself doesn=92t = cause disruption of service or end up penalizing power or performance = (which would be both ironic and bad). That=92s 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 =93swiss army knife=94 tools for = applying in a broad variety of scenarios, but they=92re 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=92re not watching (which Murphy=92s= law practically dictates will happen *especially* when you=92re not = watching), then the data collection needs to happen all the time. And yes, this is important enough to us that we=92d be willing to = contribute to the effort, not just talk about it on -hackers. ;-) - Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?89A553DC-199A-47E3-B352-34A4CDCAC4E4>