Fixed the C downstream_api messages sent by the application to NRM to be more
generic. These messages can be used to invoke power or any other policies
relying on contextual information from an application phase

See Issue #10

Added initialization of power policy using the manifest file and fixed
appropriate TODOs in `PowerPolicyManager` (PPM) Class using container
information (except adding new power policies). Also, fixed PPM to use None
instead of NONE

See Issue #10

The container creation information (resources and powerpolicy) added to
`ContainerManager` class can be used to intiliaze power policy parameters
in the present and more in the future

See Issue #10

Added damper and slowdown parameters to manifest file that can be used to
initiliaze power policy parameters

See Issue #10

Pass environment explicitly

See merge request !21

Kamil Iskra authored Aug 08, 2018 and Swann Perarnau committed Aug 09, 2018

When invoking 'argo_nodeos_config run', we were passing the job
environment implicitly.  This wasn't very clean and was also causing
problems with variables such as LD_PRELOAD, which were being filtered
out because argo_nodeos_config is suid root.

[CI] Remove CI for work-in-progress refs

See merge request !19

No need to trigger CI for things that are not ready.

Merge Power policy interface

Closes #11

See merge request !18

The Power Policy Manager will allow invocation of all power policies by the NRM
See Issue #11

DDCM based power policy is aimed to mitigate workload imbalance in parallel
applications that use barrier synchronizations (E.g. MPI). It reduces the duty
cycle of CPUs not on the critical path of execution thereby reducing energy
with little or no adverse impact on performance.

See Issue #11

Added Duty Cycle module to set, reset and check Duty Cycle of a CPU. This
module makes use of the MSR module

See Issue #11

Added Model Specific Register (MSR) module to allow access to MSRs. This module
provides the interfaces to read and write msr through msr_safe kernel module.

See Issue #11

On enabling the powepolicy manifest option and setting the policy parameter to
any valid value (except "NONE") the application library providing contextual
information is loaded using LD_PRELOAD

See issue #10

Allow applications to transmit context information to NRM (daemon)

See merge request !17

Add style checks to CI

See merge request !16

Trivial style corrections.

flake8 is an automatic style checker. This is very useful to ensure that
we have a consistent style as more people start contributing to the
code.

We ignore coolr for now, as it's a big offender.

[feature] add basic CI support

See merge request !15

Gitlab CI support, for a py.test run inside the pipenv configuration.

Convert the project to pipenv

See merge request !14

Pipenv is a recent python tool, so add a bit of documentation in the
readme for users.

Pipenv provides a reproducible description of the python packages
necessary for a python application. See the Pipenv documentation for
reference.

We also remove tox from the repo, relying instead directly on pytest.
Since we only supported one version of python, that's not a big deal.

Testing fixes

See merge request !13

Somehow missed that one.

Small fixes to correct for wrong actions on power control over a real
load.

Recent work has added and renamed binaries to the repository. This patch
syncs the setup.py file to match the current state.

This fixes missing binaries from path inside virtual environments.

Implement control loop

See merge request !12

Change the PowerActuator to be able to lower the power limit. Because
RAPL doesn't provide an actual lower limit, we use 0 as the minimal
power.

This patch adds a poweractuator based on rapl settings available through
the sensor manager. Adding this actuator forces us to use a list of
actuators in the controller, changing a bit the structure of the code.

This patch introduce one more level of abstraction to the controller:
an actuator. Actuators will act as the middleman between specific
managers and the controller, while providing enough info to implement
actual models on top.

For now, we only have the application threads actuator.

Initial support for perf wrapper

See merge request !11

The "control" part of the NRM is bound to change and become more complex
in the near future, so move it in its own module.

This refactor also introduce some controller logic. Control is split
into 3 steps: planning, execution and updates. The goal is to use this
new code organization as a way to abstract different control policies
that could be implemented later.

Note that we might at some point move into a "control manager" and a
bunch of "policies" and "actuators", as a way of matching typical
control theory vocabulary.