Hardware Reference
In-Depth Information
can't exceed 100% utilization, if we ask for 500 I/Os per second, only 425 are served
while 75 disk access requests have to sit in a queue and wait.
To keep a devices in the “good” part of their response curves is an excellent
reason to use resource limits, thus avoiding slowdowns. Four hundred requests at
40 ms is far better than 500 averaging more than 80 ms each. Some experiments
could give a rough estimate of the limit of a device, and we can use this value to
set a limit that keeps them from being driven into overload. The solution to this
problem is completed by limiting the I/Os that a task is allowed to issue. Thanks to
its I/O scheduler, which is the natural client of the block subsystem, Linux shines on
the management of resource such as disks and other input/output devices. The I/O
scheduler has been extended to understand cgroups, and can refrain from dispatching
I/Os if they will exceed the cgroup bandwidth ration. As usual, using the virtual file-
system interface, the
blockio
subsystem allows to define a [MB/s] bandwidth limit
of each char or block device node, by simply echoing that value within the provided
blockio.bandwidth
attribute.
6.3.2.4
Network Management
The control of the network bandwidth resource is straightforward by using the cgroup
framework, but slightly different with respect to the previous subsystems. As in case
of previous subsystems, a specific subsystem is provided for the resources, i.e.
tc
,
which can be used to define classes of network traffic. However, the control groups
defined are used to associate a “class id” to every network packet generated by tasks
belonging to the corresponding group. The actual bandwidth control is in charge
of the Linux traffic shaping framework, which is the client for this control group
subsystem. A command line tool allows to associate bandwidth constraints to each
class id defined by control groups.
6.3.2.5
General Conclusion on Resource Management
The first observation is about usability of the task control group framework: resource
sharing is not easy to reason about. Task control group framework only guarantees
that when the machine is loaded you get a specific resources share. However, when
the system is not loaded a task could get more, but how much is probabilistic. It
depends on everything else that is running on the machine, and at the end this can
be confusing and also hard to handle for some tasks.
Because of the hard understanding of their behaviors, one could be tempted to
only use hard limits. Hard limits are trivial to reason about, and they are genuinely
useful for preventing catastrophes, such as a disk driven into infinite slowdown.
However, hard limits should not be used as a general tool: doing so means that the
tasks can never use any spare cycles that a system has. Instead any such spare cycles
will be wasted, which is the same as wasting resources.
Search WWH ::
Custom Search