Date: Thu, 3 Apr 2014 20:48:17 +0500 From: Jordan Hubbard <jkh@ixsystems.com> To: Alan Somers <asomers@freebsd.org> 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: <7C720BEE-7440-4678-9322-988F68E6754F@ixsystems.com> In-Reply-To: <CAOtMX2gwyEYM4DthpvRO3D=BmpTNnVH-tOgiMKxC=iRr=kS6Ug@mail.gmail.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> <CAOtMX2gwyEYM4DthpvRO3D=BmpTNnVH-tOgiMKxC=iRr=kS6Ug@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 3, 2014, at 7:50 PM, Alan Somers <asomers@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=92t think this is re-inventing the wheel as much as you might = think, and here=92s 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=92t 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=92s nice for the first level of =93hmmm, = that=92s weird!=94 deduction, but then you'll immediately want to =93zoom = in=94 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=92s doing. That=92s 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=92s 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=92t 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=92ll quickly see that there=92s really not much there. = It=92s leveraging a lot of work that=92s 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=92s 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=92s 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=92s usually a bad idea, and I don=92t think we=92ve examined the = problem we want to solve in enough detail to be casting around for = solutions just yet. We=92ll have plenty of time for that later, once = we=92re all sure we=92re on the same page about what we want. Believe = me, I=92ve been through this whole exercise once before (for both mobile = and desktop devices) and it=92s nowhere near as straight-forward as it = first seems! - Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7C720BEE-7440-4678-9322-988F68E6754F>