From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 05:45:47 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 617CBE6E; Thu, 3 Apr 2014 05:45:47 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3CA1CB37; Thu, 3 Apr 2014 05:45:47 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id C8763737C9; Wed, 2 Apr 2014 22:45:46 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 56191-08; Wed, 2 Apr 2014 22:45:46 -0700 (PDT) Received: from [10.8.0.30] (unknown [10.8.0.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 925CB737C2; Wed, 2 Apr 2014 22:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1396503946; bh=9WS/oDqoVjysjWUCgzbo4cqsYEDLofWmid7I26qMoY0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=nxLrp2iVNzGkLd5Hh7/wJNb1I0lrCPQCvkHjIlj2yD60B+X2P0AyBtXlm5aqD2IfX IwecWdWp+Q7W9sQwzDkN5iBc6w3m4cBkApuIbF5NLhOGIcOjrIwLrBudB4VSMlDJWz +PP2yqrksU82vzlUX2btl2mg1IJT0sPhbPf3fd9E= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Power Efficiency (was Re: Leaving the Desktop Market) From: Jordan Hubbard In-Reply-To: <20140403034150.GA78653@regency.nsu.ru> Date: Thu, 3 Apr 2014 10:45:21 +0500 Content-Transfer-Encoding: quoted-printable Message-Id: <89A553DC-199A-47E3-B352-34A4CDCAC4E4@ixsystems.com> References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140403034150.GA78653@regency.nsu.ru> To: Alexey Dokuchaev X-Mailer: Apple Mail (2.1874) Cc: Eitan Adler , hackers@FreeBSD.org, David Chisnall X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 05:45:47 -0000 [ Dropping Advocacy and Current from the CC as this has morphed ] On Apr 3, 2014, at 8:41 AM, Alexey Dokuchaev 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