Editing UBC parameters

All the existing parameters are listed in the [[UBC parameters table]].

By importance, the parameters are divided into 3 groups: primary parameters,
secondary parameters and auxiliary parameters.
More detailed description of the parameters and the resource control
mechanisms governed by the parameters is provided below.

== General information about all parameters ==
All resource control parameters have some common properties
and some differences.

<ol>
<li>Most parameters provide both accounting of some system resource
and allow controlling its consumption.
The exceptions are <code>physpages</code> (accounting only)
and <code>vmguarpages</code> (no accounting, control only), explained below.</li>

<li>Each parameter has 2 configuration variables, called <code>barrier</code> and <code>limit</code>.

Although both 2 variables are changeable, only one or none of them may be
effectively used for the resource control for some parameters.
For example, <code>physpages</code> is an accounting-only parameter and both its
configuration variables are not effectively used in the current OpenVZ
version.

The description of each parameter explains the meaning of the <code>barrier</code>
and the <code>limit</code> and what they should be set to if they are not
effectively used.

In general, for all parameters the <code>barrier</code> should not be greater than
the <code>limit</code>.</li>

<li>The parameters control
how the resources are distributed between Virtual Environments in terms of
* limits, i.e.&nbsp;upper boundaries on what this Virtual Environment can consume, and
* guarantees, i.e.&nbsp;mechanisms ensuring that this Virtual Environment can get the assigned “resources” regardless of the activity and the amount of resources required by other Virtual Environments.

The parameters containing “<code>guar</code>” in their names,
i.e.&nbsp;<code>vmguarpages</code> and <code>oomguarpages</code> are Virtual Environment's
guarantees.
They guarantee availability of resources and certain service level
up to the value, specified by the <code>barrier</code>,
and do not guarantee above the <code>barrier</code>.
However, these parameters do not impose usage restrictions.
The guarantees are discussed in more detail in the paragraphs describing
these parameters.

The <code>limit</code> of <code>vmguarpages</code> and <code>oomguarpages</code> should be
set to the maximal value (i.e. <code>2147483647</code> on a 32-bit architecture).
</li>

<li>
For some resource limiting parameters, such as <code>kmemsize</code>,
both <code>barrier</code> and <code>limit</code> settings are effectively used.
If the resource usage exceeds the <code>barrier</code> but doesn't exceed the
<code>limit</code>, vital operations (such as process stack expansion)
are still allowed to allocate new
resources, and other ones are not allowed.
A gap between the <code>barrier</code> and the <code>limit</code> gives applications
better chances to handle resource shortage gracefully.

For other resource limiting parameters, such as <code>numproc</code>,
<code>barrier</code> and <code>limit</code> should be set to the same value.
</li>

<li>
Each parameter has “natural units of measurement” — the units
of measurement of values shown via <code>/proc/user_beancounters</code> interface and accepted by [[vzctl]].
Values related to parameters with names starting with <code>num</code> are measured
in pieces.
Values related to parameters with names ending with <code>pages</code> are measured
in memory pages (memory page is equal to 4 kilobytes on IA-32 hardware).
The remaining values (parameters ending with <code>size</code> and <code>buf</code>)
are measured in bytes.
</li>

</ol>

The properties of parameters are summarized in [[UBC parameter properties]].