ACC SHELL

Introduction
============

pm-profiler is a simple script infrastructure to enable/disable certain
power management functions via simple configuration files. It should be
able to fine tune the system in regard to specific server use cases
customers might have (and they have!). It is intended for server use where
you do not have a power management policy manager like on desktop systems
(gnome-power-manager, powerdevil, etc.).

This project might vanish in future as soon as and if, there are better
possibilities to do what it intends to do. But as of now, it seems to be
required.


The Concept of Profiles
=======================

In the past there always was the approach of so called schemes and it has
been controversly discussed whether it makes sense. While I think it
really does not make sense for desktop systems, I do think that it is
required for server systems, at least in the current point in time. Server
distributors do request a way to fine tune their systems.

So now pm-profiler is inventing this again, but somehow different, and
easier. Let us call it 'profiles' this time ;-)

Those profiles would be rather use case driven, instead of event
driven. You could have one profile for web servers, one for data storage,
one for ORACLE databases, one for mail servers, one for memory intensive
applications, one for CPU intensive applications, etc.. Those profiles
consist of simple plain text files containing string-value pairs for all
kind of different tunables in the system. For example:

     Web Server:                   Data Storage:
 DISK_PM="balanced"            DISK_PM="performance"
 NETWORK_LINK_REDUCTION="no"   NETWORK_LINK_REDUCTION="yes"
 CPUFREQ_GOVERNOR="ondemand"   CPUFREQ_GOVERNOR="performance"
 CPUFREQ_UP_THRESHOLD="40"     CPUFREQ_UP_THRESHOLD="80"
 WAKE_ON_LAN="yes"             WAKE_ON_LAN="no"

Whatever...

Linux distributors can and should provide a a default set of profiles of
which they think it makes sense to have them with default values they
think are feasible.

Of course, it is very easy to provide more profiles as time passes through
either an update process or publishing them online through user/customer
contributions.

And of course, the common goal to be smart and to have the correct and
right setting for all use cases still applies. However, this is not always
easy in the server area. Too many different use cases require too many
different settings. The general goal should always be to do the best to
keep the changes as small es possible, because we learned from the past
not to rely on workarounds and static settings.


pm-profiler Command Line Tool
=============================

A command line tool called pm-profiler is shipped with this project. It is
intended to activate a profile by hand, to list available profiles and to
read out the current system settings.


Creating Configuration Utilities for Administrators
===================================================

This concept of profiles makes it very easy to create configuration
utilities (even graphical ones) to provide an easy way for administrators
to configure their severs.

Such a GUI, ideally only should display the available pre-configured
profiles, letting an administrator chose the right one with
one single click. I don't think that every single setting should be
exposed in a user-friendly applications. Distributions and advanced
administrators should create the profiles, which in turn makes them
available in a graphical configuration utility.

A mockup of such a GUI application is provided below:

  +-------+----------------------------------------------+
  |       |                                              |
  |       |       Select Power Profile                   |
  |       |       ====================                   |
  |       | +----------+                                 |
  | Some  | |Web Server|    Profile optimized for use    |
  | Text  | +----------+    on web servers....           |
  |       | +------------+                               |
  |       | |Data Storage|  Profile optimized for data   |
  |       | +------------+  storage servers...           |
  |       |                                              |
  |       | +---------+                                  |
  |       | |ORACLE DB|     Profile optimized for use in |
  |       | +---------+     conjunction with ORACLE DBs  |
  |       |                                     +--+     |
  |       |                                     |OK|     |
  |       |                                     +--+     |
  +-------+----------------------------------------------+


PM-Profiler Implementation Details
==================================

To separate the GUI from the actual implementation, a simple shell script
infrastructure comes into operation. A configuration tool can call into it
and it can also be triggered by a runlevel script on boot. The possible
GUI can just read out the profiles, and take the appropriate actions. This
would be the easiest approach for administrators. It also makes
pm-profiler independent from any distribution. "KISS" should be the
buzzword here.

There will be one global configuration file: /etc/pm-profiler.config which
will contain one setting:

 PM_PROFILER_PROFILE="<profile name>"

If set to "", which will be the default, no profiles will be activated at
all. As a consequence, the pm-profiler will have absolutely no impact in
this case and the kernel defaults will be used. pm-profiler will only come
into operation the first time an admin selects a profile in a
configuration tool or modifies the configuration files by hand.

The profiles are defined through directory hyrarchies:

 /etc/pm-profiler/profiles/web_server/config
 /etc/pm-profiler/profiles/data_storage/config
 /etc/pm-profiler/profiles/oracle_db/config

The forth item is just an unique identifier (profile_id) for each profile.

A configuration template containing the documentation for each setting
that can be added to the profile configuration will be provided in
/usr/share/doc/packages/pm-profiler/config.template:

 [...]
 # CPU frequency scaling governor
 # Type: String
 # Possible values: powersave,performance,ondemand,conservative
 CPUFREQ_GOVERNOR="ondemand"
 [...]

To enable a profile a configuration tool has to call one single script:

 /usr/lib/pm-profiler/enable_profile <profile_id>

Only settings actually included in one specficic profile will be touched.

Each profile has a name and a description defined in the config
(PROFILE_NAME, PROFILE_DESCRIPTION). It also needs localisation. The
different language names and descriptions should be extracted, translated
and put to the appropriate places:

 /usr/share/localge/*/LC_MESSAGES/pm-profiler-<profile-name>.mo

Beside all the power management knobs we support in the config file, there
will also be a EXTERNAL_ACTION="<full path to script/program>" variable,
which will be run when the specific profile gets activated. This is empty
by default. So admins eventually could do whatever they want on profile
activation.


Do we need a Listener?
======================

We came to the conclusion, that at first, we will not need a daemon
process running listening for possible events. We just see no use case
here. So please speak up now if you see one. If it turns out that this is
required, we still can have a very small daemon which cares about possible
events that may occur, just calling the appropriate profile.