From 1daa930a76d0236bff0718fda3e5d7f9558592e6 Mon Sep 17 00:00:00 2001 From: Martin Prpic Date: Jun 09 2011 13:53:34 +0000 Subject: modified all admonitions to have a consistent title --- diff --git a/en-US/Subsystems_and_Tunable_Parameters.xml b/en-US/Subsystems_and_Tunable_Parameters.xml index 5d2b0be..0e78887 100644 --- a/en-US/Subsystems_and_Tunable_Parameters.xml +++ b/en-US/Subsystems_and_Tunable_Parameters.xml @@ -48,7 +48,7 @@ reports the total time I/O operations on specific devices by a cgroup spent waiting for service in the scheduler queues. When you interpret this report, note: - the time reported can be greater than the total time elapsed, because the time reported is the cumulative total of all I/O operations for the cgroup rather than the time that the cgroup itself spent waiting for I/O operations. To find the time that the group as a whole has spent waiting, use blkio.group_wait_time. + the time reported can be greater than the total time elapsed, because the time reported is the cumulative total of all I/O operations for the cgroup rather than the time that the cgroup itself spent waiting for I/O operations. To find the time that the group as a whole has spent waiting, use the blkio.group_wait_time parameter. @@ -144,7 +144,7 @@ cpuset The cpuset subsystem assigns individual CPUs and memory nodes to cgroups. Each cpuset can be specified according to the following parameters, each one in a separate pseudofile within the cgroup virtual file system: - Important — Mandatory Parameters + Mandatory Parameters Some subsystems have mandatory parameters that must be set before you can move a task into a cgroup which uses any of those subsystems. For example, before you move a task into a cgroup which uses the cpuset subsystem, the cpuset.cpus and cpuset.mems parameters must be defined for that cgroup. @@ -181,7 +181,7 @@ cpuset.mem_exclusive - contains a flag (0 or 1) that specifies whether other cpusets can share the memory nodes specified for this cpuset. By default (0), memory nodes are not allocated exclusively to one cpuset. Reserving memory nodes for the exclusive use of a cpuset (1) is functionally the same as enabling a memory hardwall with cpuset.mem_hardwall. + contains a flag (0 or 1) that specifies whether other cpusets can share the memory nodes specified for this cpuset. By default (0), memory nodes are not allocated exclusively to one cpuset. Reserving memory nodes for the exclusive use of a cpuset (1) is functionally the same as enabling a memory hardwall with the cpuset.mem_hardwall parameter. @@ -554,7 +554,7 @@ memory { memory.force_empty - when set to 0, empties memory of all pages used by tasks in this cgroup. This interface can only be used when the cgroup has no tasks. If memory cannot be freed, it is moved to a parent cgroup if possible. Use memory.force_empty before removing a cgroup to avoid moving out-of-use page caches to its parent cgroup. + when set to 0, empties memory of all pages used by tasks in this cgroup. This interface can only be used when the cgroup has no tasks. If memory cannot be freed, it is moved to a parent cgroup if possible. Use the memory.force_empty parameter before removing a cgroup to avoid moving out-of-use page caches to its parent cgroup. diff --git a/en-US/Using_Control_Groups.xml b/en-US/Using_Control_Groups.xml index 52a052a..8bdc69f 100644 --- a/en-US/Using_Control_Groups.xml +++ b/en-US/Using_Control_Groups.xml @@ -7,7 +7,7 @@ The easiest way to work with cgroups is to install the libcgroup package, which contains a number of cgroup-related command line utilities and their associated man pages. It is possible to mount hierarchies and set cgroup parameters (non-persistently) using shell commands and utilities available on any system. However, using the libcgroup-provided utilities simplifies the process and extends your capabilities. Therefore, this guide focuses on libcgroup commands throughout. In most cases, we have included the equivalent shell commands to help describe the underlying mechanism. However, we recommend that you use the libcgroup commands wherever practical. - Note: Installing the libcgroup package + Installing the libcgroup package In order to use cgroups, first ensure the libcgroup package is installed on your system by running, as root: ~]# yum install libcgroup @@ -108,7 +108,7 @@ group daemons/sql { - Note + Restart the <systemitem class="server">cgconfig</systemitem> service for the changes to take effect You must restart the cgconfig service for the changes in the /etc/cgconfig.conf to take effect: ~]# service cgconfig restart @@ -125,7 +125,7 @@ group daemons/sql { Creating a Hierarchy and Attaching Subsystems - Warning — Effects on running systems + Effects on running systems The following instructions, which cover creating a new hierarchy and attaching subsystems to it, assume that cgroups are not already configured on your system. In this case, these instructions will not affect the operation of the system. Changing the tunable parameters in a cgroup with tasks, however, may immediately affect those tasks. This guide alerts you the first time it illustrates changing a tunable cgroup parameter that may affect one or more tasks. On a system on which cgroups are already configured (either manually, or by the cgconfig service) these commands will fail unless you first unmount existing hierarchies, which will affect the operation of the system. Do not experiment with these instructions on production systems. @@ -299,7 +299,7 @@ blkio (optional) — specifies a user (by user ID, uid) and a group (by group ID, gid) to own the tasks pseudo-file for this cgroup. This user can add tasks to the cgroup. - Note — Removing tasks + Removing tasks Note that the only way to remove a task from a cgroup is to move it to a different cgroup. To move a task, the user must have write access to the destination cgroup; write access to the source cgroup is unimportant. @@ -376,7 +376,7 @@ blkio cpuacct]# cgset -r cpuacct.usage=0 . Note, however, that / is the preferred syntax. - Note + Setting parameters for the root group Only a small number of parameters can be set for the root group (such as the cpuacct.usage parameter shown in the examples above). This is because a root group owns all of the existing resources, therefore, it would make no sense to limit all existing processes by defining certain parameters, for example the cpuset.cpu parameter. @@ -512,11 +512,11 @@ maria:ftp devices /usergroup/staff/ftp id="Starting_a_Process"> Starting a Process in a Control Group - Important — Mandatory parameters + Mandatory parameters Some subsystems have mandatory parameters that must be set before you can move a task into a cgroup which uses any of those subsystems. For example, before you move a task into a cgroup which uses the cpuset subsystem, the cpuset.cpus and cpuset.mems parameters must be defined for that cgroup. The examples in this section illustrate the correct syntax for the command, but only work on systems on which the relevant mandatory parameters have been set for any controllers used in the examples. If you have not already configured the relevant controllers, you cannot copy example commands directly from this section and expect them to work on your system. - Refer to for a description of which parameters are mandatory for given subsystems. + Refer to for a description of which parameters are mandatory for given subsystems. @@ -634,13 +634,13 @@ CGROUP_DAEMON="cpuset:daemons/sql" id="Unloading_Control_Groups"> Unloading Control Groups - Warning — This Command Destroys all Control Groups + This Command Destroys all Control Groups The cgclear command destroys all cgroups in all hierarchies. If you do not have these hierarchies stored in a configuration file, you will not be able to readily reconstruct them. To clear an entire cgroup file system, use the cgclear command. All tasks in the cgroup are reallocated to the root node of the hierarchies, all cgroups are removed, and the file system itself is unmounted from the system, thus destroying all previously mounted hierarchies. Finally, the directory where the cgroup file system was mounted is actually deleted. - Note + Accurate listing of all mounted cgroups Using the mount command to create cgroups (as opposed to creating them using the cgconfig service) results in the creation of an entry in the /etc/mtab file (the mounted file systems table). This change is also reflected into the /proc/mounts file. However, the unloading of cgroups with the cgclear command, along with other cgconfig commands, uses a direct kernel interface which does not reflect its changes into the /etc/mtab file and only writes the new information into the /proc/mounts file. Thus, after unloading cgroups with the cgclear command, the unmounted cgroups may still be visible in the /etc/mtab file, and, consequently, displayed when the mount command is executed. It is advisable to refer to the /proc/mounts file for an accurate listing of all mounted cgroups.