|
powerd++
0.4.4
|
The powerd++ daemon is a drop-in replacement for FreeBSD's native powerd. Its purpose is to reduce the energy consumption of CPUs for the following benefits:
Contents
Powerd++ offers the following features:
The FreeBSD port is sysutils/powerdxx, the package name powerdxx.
It is not intended to run powerd++ simultaneously with powerd. To prevent this powerd++ uses the same default pidfile as powerd:
So if powerd is already setup, it first needs to be disabled:
Afterwards powerd++ can be enabled:
Comprehensive manual pages exist for powerd++ and its accompanying tools loadrec and loadplay:
The current version of the manual pages may be read directly from the repository:
The manual pages as of the last release can also be read online.
Three parameters affect the responsiveness of powerd++:
-a, -b and -n)-p)-s)The key to tuning powerd++ is the -f flag, which keeps powerd++ in foreground and causes it to report its activity. This allows directly observing the effects of a parameter set.
Observing the defaults in action may be a good start:
Note, the immediate high load is due to the load buffer being filled under the assumption that the past load fits the current clock frequency when powerd++ starts.
Please report issues and feature requests on GitHub or to kamikaze@bsdforen.de.
In case of a build issue, please report the build output as well as the output of make info:
If powerd++ behaves in some unexpected or undesired manner, please mention all the command line flags (e.g. from /etc/rc.conf powerdxx_flags) and provide a load recording:
The default recording duration is 30 s. Do not omit the -o parameter, printing the output on the terminal may create significant load and impact the recorded load significantly.
Before submitting the report, try to reproduce the behaviour using the recorded load:
The Makefile offers a set of targets, it is written for FreeBSD's make(1):
| Target | Description |
|---|---|
| all | Build everything |
| info | Print the build configuration |
| debug | Build with CXXFLAGS=-O0 -g -DEBUG |
| paranoid | Turn on undefined behaviour canaries |
| install | Install tools and manuals |
| deinstall | Deinstall tools and manuals |
| clean | Clear build directory obj/ |
| releasetest | Attempt a build and install from a gitless repo clone |
| testbuild | Test build with a set of compilers |
| tb | Alias for testbuild |
| doc | Build HTML documentation |
| gh-pages | Build and publish HTML and PDF documentation |
The all target is the default target that is called implicitly if make is run without arguments:
The debug and paranoid flags perform the same build as the all target, but with different/additional CXXFLAGS. The debug and paranoid targets can be combined.
make testbuild / make tbThe testbuild target builds all supported test builds, the list of builds can be queried from the TESTBUILDS make variable:
A specific test build may be selected by appending it to the testbuild target:
Instead of creating the default target any non-documentation target may be appended to the testbuild target:
In order to run a specific target on all test builds, the build can be omitted from the target:
The installer installs the tools and manual pages according to a recipe in pkg/files. The following variables can be passed to make install or make deinstall to affect the install destination:
| Variable | Default |
|---|---|
DESTDIR | |
PREFIX | /usr/local |
DOCSDIR | ${PREFIX}/share/doc/powerdxx |
DESTDIR can be used to install powerd++ into a chroot or jail, e.g. to put it into the staging area when building a package using the FreeBSD ports. Unlike PREFIX and DOCSDIR it does not affect the installed files themselves.
Building the documentation requires doxygen 1.8.15 or later, building the PDF version of the documentation requires xelatex as provided by the tex-xetex package.
The doc target populates doc/html and doc/latex, to create the PDF documentation doc/latex/refman.pdf must be built.
The gh-pages target builds the HTML and PDF documentation and drops it into the gh-pages submodule for publishing on github.io.
The following table provides an overview of repository contents:
| File/Folder | Contents |
|---|---|
doc/ | Output directory for doxygen documentation |
doxy/ | Doxygen configuration and filter scripts |
gh-pages/ | Submodule for publishing the documentation |
man/ | Manual pages written using mdoc(7) markup |
obj/ | Build output |
pkg/ | Installer scripts and instructions |
loads/ | Load recordings useful for testing |
src/ | C++ source files |
src/sys/ | C++ wrappers for common C interfaces |
powerd++.rc | Init script / service description |
LICENSE.md | ISC license |
Makefile | Build instructions |
README.md | Project overview |
The life cycle of the powerd++ process goes through three stages:
The first stage is designed to maximise usability by providing both, the compact short option syntax (e.g. -vfbhadp) as well as the more self-descriptive long option syntax (e.g. --verbose --foreground --batt hiadaptive).
The second stage is designed to trigger all known error conditions in order to fail before calling daemon(3) at the start of the third stage. Both the first and second stage are meant to provide specific, helpful error messages.
The third stage tracks the CPU load and performs clock frequency control. It is designed to provide its functionality with as little runtime as possible. This is achieved by:
The latter is achieved by using function templates to roll out possible runtime state combinations as multiple functions. A single, central switch/case selects the correct function each cycle. This basically rolls out multiple code paths through a single function into multiple functions with a single code path.
The trade-off made is for runtime over code size. With every bit of state rolled out like this the number of functions that need to be generated doubles, thus this approach is limited to the few bits of state that control the most expensive functionality, e.g. the foreground mode.
This project is published under the ISC license.
1.8.17