Now relies on the task_pre_launch_priv to add tasks to the
step memcg and delete it at the end of the step.
slurmstepd no longer has to be added to any memcg for the
logic to work.

Only set memory.memsw.limit_in_bytes to the computed amount of allowed
RAM+Swap when ConstrainSwapSpace=yes in cgroup.conf.
When ConstrainSwapSpace=yes and ConstrainRAMSpace=no, automatically
set AllowedRAMSpace to 100% in order to compute the memsw.limit based
on the allocated memory plus the allowed swap percent. Then use that
limit for both mem and mem+sw limits.

Using the syscalls directly rather than calling bin/(u)mount via
system() avoids a few fork + exec calls, and provides better error
handling if something goes wrong.

Users of this functionality are also updated to use slurm_strerror in
order to provide a more informative error message.

The mount and umount syscalls are Linux-specific, but so are cgroups
so no portability is lost.

Using the syscalls directly rather than calling bin/(u)mount via
system() avoids a few fork + exec calls, and provides better error
handling if something goes wrong.

Users of this functionality are also updated to use slurm_strerror in
order to provide a more informative error message.

The mount and umount syscalls are Linux-specific, but so are cgroups
so no portability is lost.

The current task/cgroup memory code writes to force_empty at job step
completion and then waits for the release agent to be triggered to
remove the memcg. However, force_empty only causes clean cache pages
to be dropped from the memcg and does not actually move charges to
the parent [1].

This has two unfortunate side-effects. First, pages that can't be
dropped by force_empty are in-use and could stay that way indefinitely
(e.g. system library that is in-use until just after force_empty
completes). Thus, the step memcg never becomes 'empty' and the release
agent is not activated. Second, cached pages that can be freed are
likely associated with the job itself, and those files and libraries
will have to be paged in again for subsequent job steps.

In contrast, calling rmdir(2) on a memcg with no active tasks
causes *all* current charges to move to parent, which is really what
we want in this case. This allows cached libraries and binaries to
stay resident and be associated with the job, and also ensures that
the step memcg is removed immediately as the job step ends.

Thus, this patch replaces the write to force_empty with a call
to xcgroup_delete() on the step memcg, which in turn removes
the memcg with rmdir(2).

The functionality of this patch depends on the previous fix that
uses xcgroup_move_process() to move slurmstepd to the root memcg.
Otherwise, there will be leftover slurmstepd threads in the job
step memcg, and the rmdir will fail with EBUSY.

 [1] Sec 4.3: http://www.kernel.org/doc/Documentation/cgroups/memory.txt

In task_cgroup_memory_fini() the implementation attempts to move
the existing slurmstepd task to the root memory cgroup by writing
the result of getpid(2) to the root memory's 'task' file. This
does not work, however, because slurmstepd is multi-threaded and
thus only the main thread is moved.

This patch replaces the explicit write to 'tasks' with a call to
the new xcgroup_move_process() call, which handles moving all
threads in the process.

In order to distinguish between slurm related cg and system related cg,
ensure that all slurm related cgroup directories are created under a
single directory. This directory is slurm or slurm_nodename in case of
multiple-slurmd usage.

Add the amount of memory allocated by slurm to the job or step
to the debug message in memcg_initialize(). Also, change the
message from debug to info, so that a user can see the information
by using --slurmd-debug=1.

For debugging purposes, add a debug level message with some values
of interest just after task_cgroup_memory has initialized.

Add a new configuration parameter MinRAMSpace which sets a lower bound on
memory.limit_in_bytes and memory.memsw.limit_in_bytes . This is required in
case an administrator or user sets an absurdly low value for memory limit,
potentially causing the slurmstepd to be terminated by the OOM killer.

MinRAMSpace is set in MB of RAM and is 30 by default. (An arbitrarily
chosen value)

The use of whole percent values for cgroup.conf parameters such
as AllowedRAMSpace, MaxRAMPercent, AllowedSwapSpace and MaxSwapPercent
may be too coarse grained on systems with large amounts of memory.
(e.g. 1% of 64G is over 650MB).

This patch allows these percentage values to be arbitrary floating
point numbers to allow finer grained tuning of these limits and
parameters.

Treat a 0 byte memory limit from SLURM as unlimited and instead use
MaxRAMPercent and MaxSwapPercent as RAM and Swap limits for the job/job
step. This avoids creating a memory cgroup with limit_in_bytes = 0,
which would end up causing the cgroup to OOM before slurmstepd could
even be started.

This also allows systems in which SLURM isn't explicitly allocating
memory to use the task/cgroup plugin with ConstrainRAMSpace=yes.

Calculate the upper bound RAM in bytes and Swap in bytes that may
be used by any one cgroup and apply this limit in the task/cgroup
code.

There was some duplicated code in task_cgroup_memory_create. In order
to facilitate extending this code in the future, refactor it into
a common function memcg_initialize().

cgroups code currently assumes cgroup subsystems will be mounted
under /cgroup, which is not the ideal location for many situations.
Add a new cgroup.conf parameter to redefine the mount point to an
arbitrary location. (for example, some systems may already have
cgroupfs mounted under /dev/cgroup or /sys/fs/cgroup)

#include <slurm/slurm.h>
to 
#include "slurm/slurm.h"
so that the original source gets searched first

+ -- Added proctrack/cgroup and task/cgroup plugins written by Matthieu
+    Hautreux, CEA.