From c39bbd14dc934f8eb6bb2148586d7a1c86299485 Mon Sep 17 00:00:00 2001 From: mprpic@REDHAT.COM Date: Mar 10 2011 12:13:34 +0000 Subject: fixed bugs: 577101, 677548; improved consistency across the whole book, retaged some elements --- diff --git a/6-trunk/en-US/Author_Group.xml b/6-trunk/en-US/Author_Group.xml index 3ff2458..43bcd52 100644 --- a/6-trunk/en-US/Author_Group.xml +++ b/6-trunk/en-US/Author_Group.xml @@ -3,6 +3,15 @@ ]> + Martin + Prpič + + Red Hat + Engineering Content Services + + mprpic@redhat.com + + Rüdiger Landmann diff --git a/6-trunk/en-US/Introduction_to_Control_Groups.xml b/6-trunk/en-US/Introduction_to_Control_Groups.xml index bd75066..9d2f2af 100644 --- a/6-trunk/en-US/Introduction_to_Control_Groups.xml +++ b/6-trunk/en-US/Introduction_to_Control_Groups.xml @@ -31,7 +31,7 @@ Multiple separate hierarchies of cgroups are necessary because each hierarchy is attached to one or more subsystems. A subsystemYou should be aware that subsystems are also called resource controllers, or simply controllers, in the libcgroup man pages and other documentation. - represents a single resource, such as CPU time or memory. &MAJOROSVER; provides nine control group subsystems, listed below by name and function. + represents a single resource, such as CPU time or memory. &MAJOROSVER; provides nine cgroup subsystems, listed below by name and function. Available Subsystems in &MAJOROS; @@ -85,7 +85,7 @@ Subsystems are also known as resource controllers - You may come across the term resource controller or simply controller in control group literature such as the man pages or kernel documentation. Both of these terms are synonymous with subsystem, and arise from the fact that a subsystem typically schedules a resource or applies a limit to the cgroups in the hierarchy it is attached to. + You may come across the term resource controller or simply controller in cgroup literature such as the man pages or kernel documentation. Both of these terms are synonymous with subsystem, and arise from the fact that a subsystem typically schedules a resource or applies a limit to the cgroups in the hierarchy it is attached to. The definition of a subsystem (resource controller) is quite general: it is something that acts upon a group of tasks, i.e. processes. @@ -131,7 +131,7 @@ class="process">http process is a member of might restrict its CPU time to half of that allotted to other processes, and limit its memory usage to a maximum of 1024 MB. Additionally, the cgroup in net that it is a member of might limit its transmission rate to 30 megabytes per second. - When the first hierarchy is created, every task on the system is a member of at least one cgroup: the root cgroup. When using control groups, therefore, every system task is always in at least one cgroup. + When the first hierarchy is created, every task on the system is a member of at least one cgroup: the root cgroup. When using cgroups, therefore, every system task is always in at least one cgroup. Are there any implications of this that we should discuss here? Is that initial cgroup-whatever it is--placing limits/constraints on all tasks in the system (absurd), or...? Conversely, if the need for splitting subsystems among separate hierarchies is reduced, you can remove a hierarchy and attach its subsystems to an existing one. - The design allows for simple control group usage, such as setting a few parameters for specific tasks in a single hierarchy, such as one with just the cpu and memory subsystems attached. + The design allows for simple cgroup usage, such as setting a few parameters for specific tasks in a single hierarchy, such as one with just the cpu and memory subsystems attached. The design also allows for highly specific configuration: each task (process) on a system could be a member of each hierarchy, each of which has a single attached subsystem. Such a configuration would give the system administrator absolute control over all parameters for every single task. diff --git a/6-trunk/en-US/Resource_Management_Guide.ent b/6-trunk/en-US/Resource_Management_Guide.ent index 78c9e8d..773b516 100644 --- a/6-trunk/en-US/Resource_Management_Guide.ent +++ b/6-trunk/en-US/Resource_Management_Guide.ent @@ -6,5 +6,5 @@ - + diff --git a/6-trunk/en-US/Subsystems_and_Tunable_Parameters.xml b/6-trunk/en-US/Subsystems_and_Tunable_Parameters.xml index b023c41..f83840f 100644 --- a/6-trunk/en-US/Subsystems_and_Tunable_Parameters.xml +++ b/6-trunk/en-US/Subsystems_and_Tunable_Parameters.xml @@ -5,54 +5,50 @@ id="ch-Subsystems_and_Tunable_Parameters"> Subsystems and Tunable Parameters - Subsystems are kernel modules that are aware of control groups. Typically, they are resource controllers that allocate varying levels of system resources to different control groups. However, subsystems could be programmed for any other interaction with the kernel where the need exists to treat different groups of processes differently. The application programming interface (API) to develop new subsystems is documented in cgroups.txt in the kernel documentation, installed on your system at /usr/share/doc/kernel-doc-kernel-version/Documentation/cgroups/. The latest version of the cgroups documentation is also available on line at Subsystems are kernel modules that are aware of cgroups. Typically, they are resource controllers that allocate varying levels of system resources to different cgroups. However, subsystems could be programmed for any other interaction with the kernel where the need exists to treat different groups of processes differently. The application programming interface (API) to develop new subsystems is documented in cgroups.txt in the kernel documentation, installed on your system at /usr/share/doc/kernel-doc-kernel-version/Documentation/cgroups/ (provided by the kernel-doc package). The latest version of the cgroups documentation is also available on line at . Note, however, that the features in the latest documentation might not match those available in the kernel installed on your system. - State objects that contain the subsystem parameters for a control group are represented as pseudofiles within the control group's virtual file system. These pseudofiles can be manipulated by shell commands or their equivalent system calls. For example, cpuset.cpus is a pseudofile that specifies which CPUs a control group is permitted to access. If /cgroup/cpuset/webserver is a control group for the web server that runs on a system, and we run the following command: + State objects that contain the subsystem parameters for a cgroup are represented as pseudofiles within the cgroup's virtual file system. These pseudofiles can be manipulated by shell commands or their equivalent system calls. For example, cpuset.cpus is a pseudofile that specifies which CPUs a cgroup is permitted to access. If /cgroup/cpuset/webserver is a cgroup for the web server that runs on a system, and we run the following command: ~]# echo 0,2 > /cgroup/cpuset/webserver/cpuset.cpus The value 0,2 is written to the cpuset.cpus pseudofile and therefore limits any tasks whose PIDs are listed in /cgroup/cpuset/webserver/tasks to use only CPU 0 and CPU 2 on the system. - - -
blkio - The blkio subsystem controls and monitors access to I/O on block devices by tasks in control groups. Writing values to some of these pseudofiles limits access or bandwidth, and reading values from some of these pseudofiles provides information on I/O operations. - + The Block I/O (blkio) subsystem controls and monitors access to I/O on block devices by tasks in cgroups. Writing values to some of these pseudofiles limits access or bandwidth, and reading values from some of these pseudofiles provides information on I/O operations. blkio.weight -specifies the relative proportion (weight) of block I/O access available by default to a control group, in the range 100 to 1000. This value is overriden for specific devices by the blkio.weight_device parameter.For example, to assign a default weight of 500 to a control group for access to block devices, run: +specifies the relative proportion (weight) of block I/O access available by default to a cgroup, in the range 100 to 1000. This value is overriden for specific devices by the blkio.weight_device parameter.For example, to assign a default weight of 500 to a cgroup for access to block devices, run: echo 500 > blkio.weight blkio.weight_device -specifies the relative proportion (weight) of I/O access on specific devices available to a control group, in the range 100 to 1000. The value of this parameter overrides the value of blkio.weight for the devices specified. Values take the format major:minor weight, where major and minor are device types and node numbers specified in Linux Allocated Devices, otherwise known as the Linux Devices List and available from . For example, to assign a weight of 500 to a control group for access to /dev/sda, run: +specifies the relative proportion (weight) of I/O access on specific devices available to a cgroup, in the range 100 to 1000. The value of this parameter overrides the value of the blkio.weight parameter for the devices specified. Values take the format major:minor weight, where major and minor are device types and node numbers specified in Linux Allocated Devices, otherwise known as the Linux Devices List and available from . For example, to assign a weight of 500 to a cgroup for access to /dev/sda, run: echo 8:0 500 > blkio.weight_device In the Linux Allocated Devices notation, 8:0 represents /dev/sda. blkio.time - reports the time that a control group had I/O access to specific devices. Entries have three fields: major, minor, and time. Major and minor are device types and node numbers specified in Linux Allocated Devices, and time is the length of time in milliseconds (ms). + reports the time that a cgroup had I/O access to specific devices. Entries have three fields: major, minor, and time. Major and minor are device types and node numbers specified in Linux Allocated Devices, and time is the length of time in milliseconds (ms). blkio.sectors - reports the number of sectors transferred to or from specific devices by a control group. Entries have three fields: major, minor, and sectors. Major and minor are device types and node numbers specified in Linux Allocated Devices, and sectors is the number of disk sectors. + reports the number of sectors transferred to or from specific devices by a cgroup. Entries have three fields: major, minor, and sectors. Major and minor are device types and node numbers specified in Linux Allocated Devices, and sectors is the number of disk sectors. blkio.io_service_bytes - reports the number of bytes transferred to or from specific devices by a control group. Entries have four fields: major, minor, operation, and bytes. Major and minor are device types and node numbers specified in Linux Allocated Devices, operation represents the type of operation (read, write, sync, or async) and bytes is the number of bytes transferred. + reports the number of bytes transferred to or from specific devices by a cgroup. Entries have four fields: major, minor, operation, and bytes. Major and minor are device types and node numbers specified in Linux Allocated Devices, operation represents the type of operation (read, write, sync, or async) and bytes is the number of bytes transferred. blkio.io_serviced - reports the number of I/O operations performed on specific devices by a control group. Entries have four fields: major, minor, operation, and bytes. Major and minor are device types and node numbers specified in Linux Allocated Devices, operation represents the type of operation (read, write, sync, or async) and number represents the number of operations. + reports the number of I/O operations performed on specific devices by a cgroup. Entries have four fields: major, minor, operation, and bytes. Major and minor are device types and node numbers specified in Linux Allocated Devices, operation represents the type of operation (read, write, sync, or async) and number represents the number of operations. blkio.io_service_time - reports the total time between request dispatch and request completion for I/O operations on specific devices by a control group. Entries have four fields: major, minor, operation, and bytes. Major and minor are device types and node numbers specified in Linux Allocated Devices, operation represents the type of operation (read, write, sync, or async) and time is the length of time in nanoseconds (ns). The time is reported in nanoseconds rather than a larger unit so that this report is meaningful even for solid-state devices. + reports the total time between request dispatch and request completion for I/O operations on specific devices by a cgroup. Entries have four fields: major, minor, operation, and bytes. Major and minor are device types and node numbers specified in Linux Allocated Devices, operation represents the type of operation (read, write, sync, or async) and time is the length of time in nanoseconds (ns). The time is reported in nanoseconds rather than a larger unit so that this report is meaningful even for solid-state devices. blkio.io_wait_time - reports the total time I/O operations on specific devices by a control group spent waiting for service in the scheduler queues. When you interpret this report, note: + 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 greated than the total time elapsed, because the time reported is the cumulative total of all I/O operations for the control group rather than the time that the control group 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 greated 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. @@ -63,26 +59,26 @@ Entries have four fields: major, minor, operation, and bytes. Major and minor are device types and node numbers specified in Linux Allocated Devices, operation represents the type of operation (read, write, sync, or async) and time is the length of time in nanoseconds (ns). The time is reported in nanoseconds rather than a larger unit so that this report is meaningful even for solid-state devices. blkio.io_merged - reports the number of BIOS requests merged into requests for I/O operations by a control group. Entries have two fields: number and operation. Number is the number of requests, and operation represents the type of operation (read, write, sync, or async). + reports the number of BIOS requests merged into requests for I/O operations by a cgroup. Entries have two fields: number and operation. Number is the number of requests, and operation represents the type of operation (read, write, sync, or async). blkio.io_queued - reports the number of requests queued for I/O operations by a control group. Entries have two fields: number and operation. Number is the number of requests, and operation represents the type of operation (read, write, sync, or async). + reports the number of requests queued for I/O operations by a cgroup. Entries have two fields: number and operation. Number is the number of requests, and operation represents the type of operation (read, write, sync, or async). blkio.avg_queue_size - reports the average queue size for I/O operations by a control group, over the entire length of time of the group's existence. The queue size is sampled every time a queue for this control group gets a timeslice. Note that this report is available only if CONFIG_DEBUG_BLK_CGROUP=y is set on the system. + reports the average queue size for I/O operations by a cgroup, over the entire length of time of the group's existence. The queue size is sampled every time a queue for this cgroup gets a timeslice. Note that this report is available only if CONFIG_DEBUG_BLK_CGROUP=y is set on the system. blkio.group_wait_time - reports the total time (in nanoseconds — ns) a control group spent waiting for a timeslice for one of its queues. The report is updated every time a queue for this control group gets a timeslice, so if you read this pseudofile while the control group is waiting for a timeslice, the report will not contain time spent waiting for the operation currently queued. Note that this report is available only if CONFIG_DEBUG_BLK_CGROUP=y is set on the system. + reports the total time (in nanoseconds — ns) a cgroup spent waiting for a timeslice for one of its queues. The report is updated every time a queue for this cgroup gets a timeslice, so if you read this pseudofile while the cgroup is waiting for a timeslice, the report will not contain time spent waiting for the operation currently queued. Note that this report is available only if CONFIG_DEBUG_BLK_CGROUP=y is set on the system. blkio.empty_time - reports the total time (in nanoseconds — ns) a control group spent without any pending requests. The report is updated every time a queue for this control group has a pending request, so if you read this pseudofile while the control group has no pending requests, the report will not contain time spent in the current empty state. Note that this report is available only if CONFIG_DEBUG_BLK_CGROUP=y is set on the system. + reports the total time (in nanoseconds — ns) a cgroup spent without any pending requests. The report is updated every time a queue for this cgroup has a pending request, so if you read this pseudofile while the cgroup has no pending requests, the report will not contain time spent in the current empty state. Note that this report is available only if CONFIG_DEBUG_BLK_CGROUP=y is set on the system. blkio.idle_time - reports the total time (in nanoseconds — ns) the scheduler spent idling for a control group in anticipation of a better request than those requests already in other queues or from other groups. The report is updated every time the group is no longer idling, so if you read this pseudofile while the control group is idling, the report will not contain time spent in the current idling state. Note that this report is available only if CONFIG_DEBUG_BLK_CGROUP=y is set on the system. + reports the total time (in nanoseconds — ns) the scheduler spent idling for a cgroup in anticipation of a better request than those requests already in other queues or from other groups. The report is updated every time the group is no longer idling, so if you read this pseudofile while the cgroup is idling, the report will not contain time spent in the current idling state. Note that this report is available only if CONFIG_DEBUG_BLK_CGROUP=y is set on the system. blkio.dequeue - reports the number of times requests for I/O operations by a control group were dequeued by specific devices. Entries have three fields: major, minor, and number. Major and minor are device types and node numbers specified in Linux Allocated Devices, and number is the number of requests the group was dequeued. Note that this report is available only if CONFIG_DEBUG_BLK_CGROUP=y is set on the system. + reports the number of times requests for I/O operations by a cgroup were dequeued by specific devices. Entries have three fields: major, minor, and number. Major and minor are device types and node numbers specified in Linux Allocated Devices, and number is the number of requests the group was dequeued. Note that this report is available only if CONFIG_DEBUG_BLK_CGROUP=y is set on the system. blkio.reset_stats resets the statistics recorded in the other pseudofiles. Write an integer to this file to reset the statistics for this cgroup. @@ -96,24 +92,24 @@
cpu - The cpu subsystem schedules CPU access to control groups. Access to CPU resources can be scheduled according to the following parameters, each one in a separate pseudofile within the control group virtual file system: + The cpu subsystem schedules CPU access to cgroups. Access to CPU resources can be scheduled according to the following parameters, each one in a separate pseudofile within the cgroup virtual file system: cpu.shares - contains an integer value that specifies a relative share of CPU time available to the tasks in a control group. For example, tasks in two control groups that have cpu.shares set to 1 will receive equal CPU time, but tasks in a control group that has cpu.shares set to 2 receive twice the CPU time of tasks in a control group where cpu.shares is set to 1. + contains an integer value that specifies a relative share of CPU time available to the tasks in a cgroup. For example, tasks in two cgroups that have cpu.shares set to 1 will receive equal CPU time, but tasks in a cgroup that has cpu.shares set to 2 receive twice the CPU time of tasks in a cgroup where cpu.shares is set to 1. cpu.rt_runtime_us - specifies a period of time in microseconds (µs, represented here as "us") for the longest continuous period in which the tasks in a control group have access to CPU resources. Establishing this limit prevents tasks in one control group from monopolizing CPU time. If the tasks in a control group should be able to access CPU resources for 4 seconds out of every 5 seconds, set cpu.rt_runtime_us to 4000000 and cpu.rt_period_us to 5000000. + specifies a period of time in microseconds (µs, represented here as "us") for the longest continuous period in which the tasks in a cgroup have access to CPU resources. Establishing this limit prevents tasks in one cgroup from monopolizing CPU time. If the tasks in a cgroup should be able to access CPU resources for 4 seconds out of every 5 seconds, set cpu.rt_runtime_us to 4000000 and cpu.rt_period_us to 5000000. cpu.rt_period_us - specifies a period of time in microseconds (µs, represented here as "us") for how regularly a control group's access to CPU resource should be reallocated. If the tasks in a control group should be able to access CPU resources for 4 seconds out of every 5 seconds, set cpu.rt_runtime_us to 4000000 and cpu.rt_period_us to 5000000. + specifies a period of time in microseconds (µs, represented here as "us") for how regularly a cgroup's access to CPU resource should be reallocated. If the tasks in a cgroup should be able to access CPU resources for 4 seconds out of every 5 seconds, set cpu.rt_runtime_us to 4000000 and cpu.rt_period_us to 5000000. @@ -121,24 +117,24 @@
cpuacct - The cpuacct subsystem generates automatic reports on CPU resources used by the tasks in a control group, including tasks in child groups. Three reports are available: + The CPU Accounting (cpuacct) subsystem generates automatic reports on CPU resources used by the tasks in a cgroup, including tasks in child groups. Three reports are available: cpuacct.stat - reports the number of CPU cycles (in the units defined by USER_HZ on the system) consumed by tasks in this control group and its children in both user mode and system (kernel) mode. + reports the number of CPU cycles (in the units defined by USER_HZ on the system) consumed by tasks in this cgroup and its children in both user mode and system (kernel) mode. cpuacct.usage - reports the total CPU time (in nanoseconds) consumed by all tasks in this control group (including tasks lower in the hierarchy). + reports the total CPU time (in nanoseconds) consumed by all tasks in this cgroup (including tasks lower in the hierarchy). cpuacct.usage_percpu - reports the CPU time (in nanoseconds) consumed on each CPU by all tasks in this control group (including tasks lower in the hierarchy). + reports the CPU time (in nanoseconds) consumed on each CPU by all tasks in this cgroup (including tasks lower in the hierarchy). @@ -146,12 +142,18 @@
cpuset - The cpuset subsystem assigns individual CPUs and memory nodes to control groups. Each cpuset can be specified according to the following parameters, each one in a separate pseudofile within the control group virtual file system: + 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 + + 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. + + cpuset.cpus (mandatory) - specifies the CPUs that tasks in this control group are permitted to access. This is a comma-separated list in ASCII format, with dashes ("-") to represent ranges. For example, + specifies the CPUs that tasks in this cgroup are permitted to access. This is a comma-separated list in ASCII format, with dashes ("-") to represent ranges. For example, 0-2,16 represents CPUs 0, 1, 2, and 16. @@ -159,7 +161,7 @@ cpuset.mems (mandatory) - specifies the memory nodes that tasks in this control group are permitted to access. This is a comma-separated list in ASCII format, with dashes ("-") to represent ranges. For example, + specifies the memory nodes that tasks in this cgroup are permitted to access. This is a comma-separated list in ASCII format, with dashes ("-") to represent ranges. For example, 0-2,16 represents memory nodes 0, 1, 2, and 16. @@ -197,7 +199,7 @@ cpuset.memory_pressure_enabled - contains a flag (0 or 1) that specifies whether the system should compute the memory pressure created by the processes in this control group. Computed values are output to cpuset.memory_pressure and represent the rate at which processes attempt to free in-use memory, reported as an integer value of attempts to reclaim memory per second, multiplied by 1000. + contains a flag (0 or 1) that specifies whether the system should compute the memory pressure created by the processes in this cgroup. Computed values are output to cpuset.memory_pressure and represent the rate at which processes attempt to free in-use memory, reported as an integer value of attempts to reclaim memory per second, multiplied by 1000. @@ -216,7 +218,7 @@ cpuset.sched_load_balance contains a flag (0 or 1) that specifies whether the kernel will balance loads across the CPUs in this cpuset. By default (1), the kernel balances loads by moving processes from overloaded CPUs to less heavily used CPUs. - Note, however, that setting this flag in a control group has no effect if load balancing is enabled in any parent control group, as load balancing is already being carried out at a higher level. Therefore, to disable load balancing in a control group, disable load balancing also in each of its parents in the hierarchy. In this case, you should also consider whether load balancing should be enabled for any siblings of the control group in question. + Note, however, that setting this flag in a cgroup has no effect if load balancing is enabled in any parent cgroup, as load balancing is already being carried out at a higher level. Therefore, to disable load balancing in a cgroup, disable load balancing also in each of its parents in the hierarchy. In this case, you should also consider whether load balancing should be enabled for any siblings of the cgroup in question. @@ -278,20 +280,20 @@
devices - The devices subsystem allows or denies access to devices by tasks in a control group. + The devices subsystem allows or denies access to devices by tasks in a cgroup. Technology Preview - The devices subsystem is considered to be a Technology Preview in Red Hat Enterprise Linux &PRODVER;. + The Device Whitelist (devices) subsystem is considered to be a Technology Preview in Red Hat Enterprise Linux &PRODVER;. Technology preview features are currently not supported under Red Hat Enterprise Linux &PRODVER; subscription services, might not be functionally complete, and are generally not suitable for production use. However, Red Hat includes these features in the operating system as a customer convenience and to provide the feature with wider exposure. You might find these features useful in a non-production environment and are also free to provide feedback and functionality suggestions for a technology preview feature before it becomes fully supported. devices.allow - specifies devices to which tasks in a control group have access. Each entry has four fields: type, major, minor, and access. The values used in the type, major, and minor fields correspond to device types and node numbers specified in Linux Allocated Devices, otherwise known as the Linux Devices List and available from specifies devices to which tasks in a cgroup have access. Each entry has four fields: type, major, minor, and access. The values used in the type, major, and minor fields correspond to device types and node numbers specified in Linux Allocated Devices, otherwise known as the Linux Devices List and available from . @@ -354,13 +356,13 @@ devices.deny - specifies devices that tasks in a control group cannot access. The syntax of entries is identical with devices.allow. + specifies devices that tasks in a cgroup cannot access. The syntax of entries is identical with devices.allow. devices.list - reports the devices for which access controls have been set for tasks in this control group. + reports the devices for which access controls have been set for tasks in this cgroup. @@ -368,7 +370,7 @@
freezer - The freezer subsystem suspends or resumes tasks in a control group. + The freezer subsystem suspends or resumes tasks in a cgroup. freezer.state @@ -378,26 +380,29 @@ - FROZEN — tasks in the control group are suspended. + FROZEN — tasks in the cgroup are suspended. - FREEZING — the system is in the process of suspending tasks in the control group. + FREEZING — the system is in the process of suspending tasks in the cgroup. - THAWED — tasks in the control group have resumed. + THAWED — tasks in the cgroup have resumed. + + To suspend a specific process, first, you must move that process to a cgroup in a hierarchy which has the freezer subsystem attached to it. Consequently, freeze that particular cgroup to suspend the task contained in it. It is not possible to move a task into a suspended (frozen) cgroup. + Note that while the FROZEN and THAWED values can be written to freezer.state, FREEZING cannot be written, only read.
memory - The memory subsystem generates automatic reports on memory resources used by the tasks in a control group, and sets limits on memory use by those tasks: + The memory subsystem generates automatic reports on memory resources used by the tasks in a cgroup, and sets limits on memory use by those tasks: memory.stat @@ -442,7 +447,7 @@ - Additionally, each of these files other than hierarchical_memory_limit and hierarchical_memsw_limit has a counterpart prefixed total_ that reports not only on the control group, but on all its children as well. For example, swap reports the swap usage by a control group and total_swap reports the total swap usage by the control group and all its child groups. + Additionally, each of these files other than hierarchical_memory_limit and hierarchical_memsw_limit has a counterpart prefixed total_ that reports not only on the cgroup, but on all its children as well. For example, swap reports the swap usage by a cgroup and total_swap reports the total swap usage by the cgroup and all its child groups. When you interpret the values reported by memory.stat, note how the various statistics inter-relate: @@ -456,25 +461,25 @@ memory.usage_in_bytes - reports the total current memory usage by processes in the control group (in bytes). + reports the total current memory usage by processes in the cgroup (in bytes). memory.memsw.usage_in_bytes - reports the sum of current memory usage plus swap space used by processes in the control group (in bytes). + reports the sum of current memory usage plus swap space used by processes in the cgroup (in bytes). memory.max_usage_in_bytes - reports the maximum memory used by processes in the control group (in bytes). + reports the maximum memory used by processes in the cgroup (in bytes). memory.memsw.max_usage_in_bytes - reports the maximum amount of memory and swap space used by processes in the control group (in bytes). + reports the maximum amount of memory and swap space used by processes in the cgroup (in bytes). @@ -482,7 +487,7 @@ sets the maximum amount of user memory (including file cache). If no units are specified, the value is interpreted as bytes. However, it is possible to use suffixes to represent larger units — k or K for kilobytes, m or M for Megabytes, and g or G for Gigabytes. - You cannot use memory.limit_in_bytes to limit the root control group; you can only apply values to groups lower in the hierarchy. + You cannot use memory.limit_in_bytes to limit the root cgroup; you can only apply values to groups lower in the hierarchy. Write -1 to memory.limit_in_bytes to remove any existing limits. @@ -494,7 +499,7 @@ sets the maximum amount for the sum of memory and swap usage. If no units are specified, the value is interpreted as bytes. However, it is possible to use suffixes to represent larger units — k or K for kilobytes, m or M for Megabytes, and g or G for Gigabytes. - You cannot use memory.memsw.limit_in_bytes to limit the root control group; you can only apply values to groups lower in the hierarchy. + You cannot use memory.memsw.limit_in_bytes to limit the root cgroup; you can only apply values to groups lower in the hierarchy. Write -1 to memory.memsw.limit_in_bytes to remove any existing limits. @@ -516,20 +521,20 @@ memory.force_empty - when set to 0, empties memory of all pages used by tasks in this control group. This interface can only be used when the control group has no tasks. If memory cannot be freed, it is moved to a parent control group if possible. Use memory.force_empty before removing a control group to avoid moving out-of-use page caches to its parent control group. + 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. memory.swappiness - sets the tendency of the kernel to swap out process memory used by tasks in this control group instead of reclaiming pages from the page cache. This is the same tendency, calculated the same way, as set in /proc/sys/vm/swappiness for the system as a whole. The default value is 60. Values lower than 60 decrease the kernel's tendency to swap out process memory, values greater than 60 increase the kernel's tendency to swap out process memory, and values greater than 100 permit the kernel to swap out pages that are part of the address space of the processes in this control group. + sets the tendency of the kernel to swap out process memory used by tasks in this cgroup instead of reclaiming pages from the page cache. This is the same tendency, calculated the same way, as set in /proc/sys/vm/swappiness for the system as a whole. The default value is 60. Values lower than 60 decrease the kernel's tendency to swap out process memory, values greater than 60 increase the kernel's tendency to swap out process memory, and values greater than 100 permit the kernel to swap out pages that are part of the address space of the processes in this cgroup. Note that a value of 0 does not prevent process memory being swapped out; swap out might still happen when there is a shortage of system memory because the global virtual memory management logic does not read the cgroup value. To lock pages completely, use mlock() instead of cgroups. You cannot change the swappiness of the following groups: - the root control group, which uses the swappiness set in /proc/sys/vm/swappiness. - a control group that has child groups below it. + the root cgroup, which uses the swappiness set in /proc/sys/vm/swappiness. + a cgroup that has child groups below it. @@ -537,7 +542,7 @@ memory.use_hierarchy - contains a flag (0 or 1) that specifies whether memory usage should be accounted for throughout a hierarchy of control groups. If enabled (1), the memory controller reclaims memory from the children of and process that exceeds its memory limit. By default (0), the controller does not reclaim memory from a task's children. + contains a flag (0 or 1) that specifies whether memory usage should be accounted for throughout a hierarchy of cgroups. If enabled (1), the memory subsystem reclaims memory from the children of and process that exceeds its memory limit. By default (0), the subsystem does not reclaim memory from a task's children. @@ -545,7 +550,7 @@
net_cls - The net_cls subsystem tags network packets with a class identifier (classid) that allows the Linux traffic controller (tc) to identify packets originating from a particular control group. The traffic controller can be configured to assign different priorities to packets from different control groups. + The net_cls subsystem tags network packets with a class identifier (classid) that allows the Linux traffic controller (tc) to identify packets originating from a particular cgroup. The traffic controller can be configured to assign different priorities to packets from different cgroups. net_cls.classid @@ -571,7 +576,7 @@ id="itemlist-Subsystem-Specific_Kernel_Documentation"> Subsystem-Specific Kernel Documentation All of the following files are located under the /usr/share/doc/kernel-doc-<kernel_version>/Documentation/cgroups/ directory. + class="directory">/usr/share/doc/kernel-doc-<kernel_version>/Documentation/cgroups/ directory (provided by the kernel-doc package). Using Control Groups - The easiest way to work with control groups 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. + 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 In order to use cgroups, first ensure the libcgroup package is installed on your system by running, as root: @@ -16,13 +16,13 @@ id="The_cgconfig_Service"> The cgconfig Service The cgconfig service installed with the libcgroup package provides a convenient way to create hierarchies, attach subsystems to hierarchies, and manage cgroups within those hierarchies. We recommend that you use cgconfig to manage hierarchies and cgroups on your system. - The cgconfig service is not started by default on Red Hat Enterprise Linux &PRODVER;. When you start the service with chkconfig, it reads the control group configuration file — /etc/cgconfig.conf. Control groups are therefore recreated from session to session and become persistent. Depending on the contents of the configuration file, cgconfig can create hierarchies, mount necessary file systems, create control groups, and set subsystem parameters for each group. - The default cgconfig.conf file installed with the libcgroup package creates and mounts an individual hierarchy for each subsystem, and attaches the subsystems to these hierarchies. + The cgconfig service is not started by default on Red Hat Enterprise Linux &PRODVER;. When you start the service with chkconfig, it reads the cgroup configuration file — /etc/cgconfig.conf. Cgroups are therefore recreated from session to session and become persistent. Depending on the contents of the configuration file, cgconfig can create hierarchies, mount necessary file systems, create cgroups, and set subsystem parameters for each group. + The default /etc/cgconfig.conf file installed with the libcgroup package creates and mounts an individual hierarchy for each subsystem, and attaches the subsystems to these hierarchies. If you stop the cgconfig service (with the service cgconfig stop command), it unmounts all the hierarchies that it mounted.
The cgconfig.conf File - The cgconfig.conf file contains two major types of entry — mount and group. Mount entries create and mount hierarchies as virtual filesystems, and attach subsystems to those hierarchies. Mount entries are defined using the following syntax: + The /etc/cgconfig.conf file contains two major types of entry — mount and group. Mount entries create and mount hierarchies as virtual filesystems, and attach subsystems to those hierarchies. Mount entries are defined using the following syntax: mount { <controller> = <path>; @@ -50,7 +50,7 @@ mount { - Group entries create control groups and set subsystem parameters. Group entries are defined using the following syntax: + Group entries create cgroups and set subsystem parameters. Group entries are defined using the following syntax: group <name> { <permissions> @@ -82,7 +82,7 @@ perm { Creating a group entry - The following example creates a control group for sql daemons, with permissions for users in the sqladmin group to add tasks to the control group and the root user to modify subsystem parameters: + The following example creates a cgroup for sql daemons, with permissions for users in the sqladmin group to add tasks to the cgroup and the root user to modify subsystem parameters: group daemons/sql { @@ -126,8 +126,8 @@ group daemons/sql { Warning — Effects on running systems - The following instructions, which cover creating a new hierarchy and attaching subsystems to it, assume that control groups 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 control groups 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. + 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. To create a hierarchy and attach subsystems to it, edit the mount section of the /etc/cgconfig.conf file as root. Entries in the mount section have the following format: subsystem = /cgroup/hierarchy; @@ -149,7 +149,7 @@ group daemons/sql { mkdir -p /cgroup/lab1 --> - Create a mount point for the hierarchy as root. Include the name of the control group in the mount point: + Create a mount point for the hierarchy as root. Include the name of the cgroup in the mount point: ~]# mkdir /cgroup/name For example: ~]# mkdir /cgroup/cpu_and_mem @@ -229,7 +229,6 @@ blkio ~]# lssubsys -am cpu,cpuset,memory,net_cls /cgroup/lab1 ns -cpu cpuacct devices freezer @@ -243,7 +242,7 @@ blkio class="resource">net_cls subsystems attached to it): --> To add an unattached subsystem to an existing hierarchy, remount the hierarchy. Include the extra subsystem in the mount command, together with the option. -Remounting a hierarchy to add a subsystem +Remounting a hierarchy to add a subsystem The lssubsys command shows cpu, cpuset, and memory subsystems attached to the cpu_and_mem hierarchy: ~]# lssubsys -am cpu,cpuset,memory /cgroup/cpu_and_mem @@ -282,14 +281,14 @@ blkio For example: ~]# umount /cgroup/cpu_and_mem If the hierarchy is currently empty (that is, it contains only the root cgroup) the hierarchy is deactivated when it is unmounted. If the hierarchy contains any other cgroups, the hierarchy remains active in the kernel even though it is no longer mounted. - To remove a hierarchy, ensure that all child cgroups are removed before you unmount the hierarchy, or use the cgclear command which can deactivate a hierarchy even when it is not empty — refer to . + To remove a hierarchy, ensure that all child cgroups are removed before you unmount the hierarchy, or use the cgclear command which can deactivate a hierarchy even when it is not empty — refer to .
- Creating Cgroups + Creating Control Groups Use the cgcreate command to create cgroups. The syntax for cgcreate is: cgcreate uid:gid @@ -299,22 +298,22 @@ blkio - (optional) — specifies a user (by user ID, uid) and a group (by group ID, gid) to own the tasks pseudofile for this control group. This user can add tasks to the control group. + (optional) — specifies a user (by user ID, uid) and a group (by group ID, gid) to own the tasks pseudofile for this cgroup. This user can add tasks to the cgroup. Note — Removing tasks - Note that the only way to remove a task from a control group is to move it to a different control group. To move a task, the user must have write access to the destination control group; write access to the source control group is unimportant. + 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. - (optional) — specifies a user (by user ID, uid) and a group (by group ID, gid) to own all pseudofiles other than tasks for this control group. This user can modify the access that the tasks in this control group have to system resources. + (optional) — specifies a user (by user ID, uid) and a group (by group ID, gid) to own all pseudofiles other than tasks for this cgroup. This user can modify the access that the tasks in this cgroup have to system resources. — specifies the hierarchy in which the cgroup should be created, as a comma-separated list of the subsystems associated with those hierarchies. If the subsystems in this list are in different hierarchies, the group is created in each of these hierarchies. The list of hierarchies is followed by a colon and the path to the child group relative to the hierarchy. Do not include the hierarchy mount point in the path. - For example, the control group located in the directory /cgroup/cpu_and_mem/lab1/ is called just lab1 — its path is already uniquely determined because there is at most one hierarchy for a given subsystem. Note also that the group is controlled by all the subsystems that exist in the hierarchies in which the cgroup is created, even though these subsystems have not been specified in the cgcreate command — refer to . + For example, the cgroup located in the directory /cgroup/cpu_and_mem/lab1/ is called just lab1 — its path is already uniquely determined because there is at most one hierarchy for a given subsystem. Note also that the group is controlled by all the subsystems that exist in the hierarchies in which the cgroup is created, even though these subsystems have not been specified in the cgcreate command — refer to . - Because all control groups in the same hierarchy have the same controllers, the child group has the same controllers as its parent. + Because all cgroups in the same hierarchy have the same controllers, the child group has the same controllers as its parent. cgcreate usage Consider a system where the cpu and memory subsystems are mounted together in the cpu_and_mem hierarchy, and the net_cls controller is mounted in a separate hierarchy called net. We now run: @@ -322,7 +321,7 @@ blkio The cgcreate command creates two groups named test-subgroup, one in the cpu_and_mem hierarchy and one in the net hierarchy. The test-subgroup group in the cpu_and_mem hierarchy is controlled by the memory subsystem, even though we did not specify it in the cgcreate command. Alternative method -To create a child of the control group directly, use the mkdir command: +To create a child of the cgroup directly, use the mkdir command: ~]# mkdir /cgroup/hierarchy/name/child_name For example: ~]# mkdir /cgroup/cpuset/lab1/group1 @@ -330,7 +329,7 @@ blkio
- Removing Cgroups + Removing Control Groups Remove cgroups with the cgdelete, which has a syntax similar to that of cgcreate. Run: cgdelete subsystems:path, where: @@ -350,12 +349,12 @@ blkio cgdelete can also recursively remove all subgroups with the option . - When you delete a control group, all its tasks move to its parent group. + When you delete a cgroup, all its tasks move to its parent group.
Setting Parameters - Set subsystem parameters by running the cgset command from a user account with permission to modify the relevant control group. For example, if /cgroup/cpuset/group1 exists, specify the CPUs to which this group has access with the following command: + Set subsystem parameters by running the cgset command from a user account with permission to modify the relevant cgroup. For example, if /cgroup/cpuset/group1 exists, specify the CPUs to which this group has access with the following command: cpuset]# cgset -r cpuset.cpus=0-1 group1 The syntax for cgset is: cgset parameter=value path_to_cgroup @@ -371,7 +370,7 @@ blkio - path_to_cgroup is the path to the control group relative to the root of the hierarchy. For example, to set the parameter of the root group (if /cgroup/cpuacct/ exists), run: + path_to_cgroup is the path to the cgroup relative to the root of the hierarchy. For example, to set the parameter of the root group (if /cgroup/cpuacct/ exists), run: cpuacct]# cgset -r cpuacct.usage=0 / Alternatively, because . is relative to the root group (that is, the root group itself) you could also run: cpuacct]# cgset -r cpuacct.usage=0 . @@ -379,7 +378,7 @@ blkio Note - 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. + 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. @@ -398,20 +397,20 @@ blkio - path_to_source_cgroup is the path to the control group whose parameters are to be copied, relative to the root group of the hierarchy + path_to_source_cgroup is the path to the cgroup whose parameters are to be copied, relative to the root group of the hierarchy - path_to_target_cgroup is the path to the destination control group, relative to the root group of the hierarchy + path_to_target_cgroup is the path to the destination cgroup, relative to the root group of the hierarchy - Ensure that any mandatory parameters for the various subsystems are set before you copy parameters from one group to another, or the command will fail. + Ensure that any mandatory parameters for the various subsystems are set before you copy parameters from one group to another, or the command will fail. For more information on mandatory parameters, refer to . Alternative method - To set parameters in a control group directly, insert values into the relevant subsystem pseudofile using the echo command. For example, this command inserts the value 0-1 into the cpuset.cpus pseudofile of the control group group1: + To set parameters in a cgroup directly, insert values into the relevant subsystem pseudofile using the echo command. For example, this command inserts the value 0-1 into the cpuset.cpus pseudofile of the cgroup group1: ~]# echo 0-1 > /cgroup/cpuset/group1/cpuset.cpus - With this value in place, the tasks in this control group are restricted to CPUs 0 and 1 on the system. + With this value in place, the tasks in this cgroup are restricted to CPUs 0 and 1 on the system.
@@ -420,26 +419,26 @@ blkio id="sec-Moving_a_Process_to_a_Control_Group"> Moving a Process to a Control Group -Move a process into a control group by running the cgclassify command: +Move a process into a cgroup by running the cgclassify command: ~]# cgclassify -g cpu,memory:group1 1701 The syntax for cgclassify is: cgclassify subsystems:path_to_cgroup pidlist, where: - subsystems is a comma-separated list of subsystems, or * to launch the process in the hierarchies associated with all available subsystems. Note that if control groups of the same name exist in multiple hierarchies, the option moves the processes in each of those groups. Ensure that the cgroup exists within each of the hierarchies whose subsystems you specify here. + subsystems is a comma-separated list of subsystems, or * to launch the process in the hierarchies associated with all available subsystems. Note that if cgroups of the same name exist in multiple hierarchies, the option moves the processes in each of those groups. Ensure that the cgroup exists within each of the hierarchies whose subsystems you specify here. - path_to_cgroup is the path to the control group within its hierarchies + path_to_cgroup is the path to the cgroup within its hierarchies pidlist is a space-separated list of process identifier (PIDs) - You can also add the option before the pid to keep any child processes in the same control group. If you do not set this option and the cgred daemon is running, child processes will be allocated to control groups based on the settings found in /etc/cgrules.conf. The process itself, however, will remain in the control group in which you started it. - Using cgclassify, you can move several processes simultaneously. For example, this command moves the processes with PIDs 1701 and 1138 into control group group1/: + You can also add the option before the pid to keep any child processes in the same cgroup. If you do not set this option and the cgred daemon is running, child processes will be allocated to cgroups based on the settings found in /etc/cgrules.conf. The process itself, however, will remain in the cgroup in which you started it. + Using cgclassify, you can move several processes simultaneously. For example, this command moves the processes with PIDs 1701 and 1138 into cgroup group1/: ~]# cgclassify -g cpu,memory:group1 1701 1138 Note that the PIDs to be moved are separated by spaces and that the groups specified should be in different hierarchies. @@ -447,7 +446,7 @@ blkio Alternative method - To move a process into a control group directly, write its PID to the tasks file of the control group. For example, to move a process with the PID 1701 into a control group at /cgroup/lab1/group1/: + To move a process into a cgroup directly, write its PID to the tasks file of the cgroup. For example, to move a process with the PID 1701 into a cgroup at /cgroup/lab1/group1/: ~]# echo 1701 > /cgroup/lab1/group1/tasks @@ -455,7 +454,7 @@ blkio id="The_cgred_Daemon"> The cgred Daemon - Cgred is a daemon that moves tasks into control groups according to parameters set in the /etc/cgrules.conf file. Entries in the /etc/cgrules.conf file can take one of the two forms: + Cgred is a daemon that moves tasks into cgroups according to parameters set in the /etc/cgrules.conf file. Entries in the /etc/cgrules.conf file can take one of the two forms: @@ -476,11 +475,11 @@ blkio maria devices /usergroup/staff - This entry specifies that any processes that belong to the user named maria access the devices subsystem according to the parameters specified in the /usergroup/staff control group. To associate particular commands with particular control groups, add the command parameter, as follows: + This entry specifies that any processes that belong to the user named maria access the devices subsystem according to the parameters specified in the /usergroup/staff cgroup. To associate particular commands with particular cgroups, add the command parameter, as follows: maria:ftp devices /usergroup/staff/ftp -The entry now specifies that when the user named maria uses the ftp command, the process is automatically moved to the /usergroup/staff/ftp control group in the hierarchy that contains the devices subsystem. Note, however, that the daemon moves the process to the control group only after the appropriate condition is fulfilled. Therefore, the ftp process might run for a short time in the wrong group. Furthermore, if the process quickly spawns children while in the wrong group, these children might not be moved. +The entry now specifies that when the user named maria uses the ftp command, the process is automatically moved to the /usergroup/staff/ftp cgroup in the hierarchy that contains the devices subsystem. Note, however, that the daemon moves the process to the cgroup only after the appropriate condition is fulfilled. Therefore, the ftp process might run for a short time in the wrong group. Furthermore, if the process quickly spawns children while in the wrong group, these children might not be moved. @@ -512,9 +511,9 @@ maria:ftp devices /usergroup/staff/ftp
Starting a Process in a Control Group - + Important — Mandatory parameters - Some controllers have mandatory parameters that you must set before you run a task in a hierarchy that includes those controllers. For example, before you use the cpuset controller, cpuset.cpus and cpuset.mems must be defined. + 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. @@ -523,7 +522,7 @@ maria:ftp devices /usergroup/staff/ftp - Launch processes in a control group by running the cgexec command. For example, this command launches the lynx web browser within the group1 control group, subject to the limitations imposed on that group by the cpu subsystem: + Launch processes in a cgroup by running the cgexec command. For example, this command launches the lynx web browser within the group1 cgroup, subject to the limitations imposed on that group by the cpu subsystem: ~]# cgexec -g cpu:group1 lynx http://www.redhat.com The syntax for cgexec is: cgexec subsystems:path_to_cgroup command arguements @@ -531,11 +530,11 @@ maria:ftp devices /usergroup/staff/ftp - subsystems is a comma-separated list of subsystems, or * to launch the process in the hierarchies associated with all available subsystems. Note that, as with cgset described in , if control groups of the same name exist in multiple hierarchies, the option creates processes in each of those groups. Ensure that the cgroup exists within each of the hierarchies whose subsystems you specify here. + subsystems is a comma-separated list of subsystems, or * to launch the process in the hierarchies associated with all available subsystems. Note that, as with cgset described in , if cgroups of the same name exist in multiple hierarchies, the option creates processes in each of those groups. Ensure that the cgroup exists within each of the hierarchies whose subsystems you specify here. - path_to_cgroup is the path to the control group relative to the hierarchy. + path_to_cgroup is the path to the cgroup relative to the hierarchy. @@ -546,15 +545,15 @@ maria:ftp devices /usergroup/staff/ftp arguements are any arguements for the command - You can also add the option before the command to keep any child processes in the same control group. If you do not set this option and the cgred daemon is running, child processes will be allocated to control groups based on the settings found in /etc/cgrules.conf. The process itself, however, will remain in the control group in which you started it. + You can also add the option before the command to keep any child processes in the same cgroup. If you do not set this option and the cgred daemon is running, child processes will be allocated to cgroups based on the settings found in /etc/cgrules.conf. The process itself, however, will remain in the cgroup in which you started it. Alternative method - When you start a new process, it inherits the group of its parent process. Therefore, an alternative method for starting a process in a particular control group is to move your shell process to that group (refer to ), and then launch the process from that shell. For example: + When you start a new process, it inherits the group of its parent process. Therefore, an alternative method for starting a process in a particular cgroup is to move your shell process to that group (refer to ), and then launch the process from that shell. For example: ~]# echo $$ > /cgroup/lab1/group1/tasks lynx -Note that after exiting lynx, your existing shell is still in the group1 control group. Therefore, an even better way would be: +Note that after exiting lynx, your existing shell is still in the group1 cgroup. Therefore, an even better way would be: ~]# sh -c "echo \$$ > /cgroup/lab1/group1/tasks && lynx" @@ -564,13 +563,13 @@ maria:ftp devices /usergroup/staff/ftp id="Starting_a_Service"> Starting a Service in a Control Group - You can start some services in a control group. Services that can be started in control groups must: + You can start certain services in a cgroup. Services that can be started in cgroups must: use a /etc/sysconfig/servicename file use the daemon() function from /etc/init.d/functions to start the service - To make an eligible service start in a control group, edit its file in the /etc/sysconfig directory to include an entry in the form CGROUP_DAEMON="subsystem:control_group" where subsystem is a subsystem associated with a particular hierarchy, and control_group is a control group in that hierarchy. For example: + To make an eligible service start in a cgroup, edit its file in the /etc/sysconfig directory to include an entry in the form CGROUP_DAEMON="subsystem:control_group" where subsystem is a subsystem associated with a particular hierarchy, and control_group is a cgroup in that hierarchy. For example: CGROUP_DAEMON="cpuset:daemons/sql" @@ -582,7 +581,7 @@ CGROUP_DAEMON="cpuset:daemons/sql"
Finding a Process - To find the control group to which a process belongs, run: + To find the cgroup to which a process belongs, run: ~]$ ps -O cgroup Or, if you know the PID for the process, run: ~]$ cat /proc/PID/cgroup @@ -604,26 +603,26 @@ CGROUP_DAEMON="cpuset:daemons/sql"
Finding Hierarchies - We recommend that you mount hierarchies under /cgroup. Assuming this is the case on your system, list or browse the contents of that directory to obtain a list of hierarchies. If tree is installed on your system, run it to obtain an overview of all hierarchies and the control groups within them: + We recommend that you mount hierarchies under /cgroup. Assuming this is the case on your system, list or browse the contents of that directory to obtain a list of hierarchies. If tree is installed on your system, run it to obtain an overview of all hierarchies and the cgroups within them: ~]$ tree /cgroup/
Finding Control Groups - To list the control groups on a system, run: + To list the cgroups on a system, run: ~]$ lscgroup You can restrict the output to a specific hierarchy by specifying a controller and path in the format controller:path. For example: ~]$ lscgroup cpuset:adminusers - lists only subgroups of the adminusers control group in the hierarchy to which the cpuset subsystem is attached. + lists only subgroups of the adminusers cgroup in the hierarchy to which the cpuset subsystem is attached.
Displaying Parameters of Control Groups - To display the parameters of specific control groups, run: + To display the parameters of specific cgroups, run: ~]$ cgget -r parameter list_of_cgroups - where parameter is a pseudofile that contains values for a subsystem, and list_of_cgroups is a list of control groups separated with spaces. For example: + where parameter is a pseudofile that contains values for a subsystem, and list_of_cgroups is a list of cgroups separated with spaces. For example: ~]$ cgget -r cpuset.cpus -r memory.limit_in_bytes lab1 lab2 - displays the values of cpuset.cpus and memory.limit_in_bytes for control groups lab1 and lab2. + displays the values of cpuset.cpus and memory.limit_in_bytes for cgroups lab1 and lab2. If you do not know the names of the parameters themselves, use a command like: @@ -631,25 +630,27 @@ CGROUP_DAEMON="cpuset:daemons/sql"
- - - -
- Unloading Groups + id="Unloading_Control_Groups"> + Unloading Control Groups Warning — This Command Destroys all Control Groups - The cgclear command destroys all control groups in all hierarchies. If you do not have these hierarchies stored in a configuration file, you will not be able to readily reconstruct them. + 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 control group file system, use the cgclear command. - All tasks in the control group are reallocated to the root node of the hierarchies, all control groups are removed, and the filesystem itself is unmounted from the system, thus destroying all previously mounted hierarchies. Finally, the directory where the cgroup filesystem was mounted is actually deleted. + 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 filesystem itself is unmounted from the system, thus destroying all previously mounted hierarchies. Finally, the directory where the cgroup filesystem was mounted is actually deleted. + + Note + + Using the mount command to create cgroups (as oposed 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 it's 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. + +
Additional Resources - The definitive documentation for control group commands are the manual pages provided with the libcgroup package. The section numbers are specified in the list of man pages below. + The definitive documentation for cgroup commands are the manual pages provided with the libcgroup package. The section numbers are specified in the list of man pages below. The libcgroup Man Pages