Vale checks for tuning guide

Vale checks for tuning guide

Vale checks for tuning guide

Vale style checks for tuning guide

Vale style checks for tuning guide

Vale style checks for tuning guide

Vale style checks for tuning guide

Vale style checks for tuning guide

Vale style checks for tuning guide

Vale style checks for tuning guide

Vale style checks for tuning guide

Vale style checks for tuning guide

Vale style checks for tuning guide

Vale style checks for tuning guide

Vale style checks for tuning guide

Vale checks for tuning guide

Vale checks for tuning guide

Vale style checks for tuning guide

Vale style checks for tuning guide

Vale style checks for tuning guide

Revisions based on Daria's review

MInor fix after rebasing with main

Revisedcontent based on Daria's second round of review

Revisions based on Daria's comment

xml/tuning_cgroups.xml

@@ -37,7 +37,7 @@
   <para>
    Every process is assigned exactly one administrative cgroup. cgroups are
    ordered in a hierarchical tree structure. You can set resource
-   limitations, such as CPU, memory, disk I/O, or network bandwidth usage,
+   limitations such as CPU, memory, disk I/O, or network bandwidth usage,
    for single processes or for whole branches of the hierarchy tree.
   </para>
 
@@ -52,9 +52,8 @@
   </para>
 
   <para>
-   The kernel cgroup API comes in two variants, v1 and v2. Additionally,
-   there can be multiple cgroup hierarchies exposing different APIs. From
-   the numerous possible combinations, there are two practical choices:
+   The kernel cgroup API comes in two variants&mdash;v1 and v2. Additionally,
+   there can be multiple cgroup hierarchies exposing different APIs. From many possible combinations, there are two practical choices:
   </para>
   <itemizedlist>
    <listitem>
@@ -98,7 +97,7 @@
   </listitem>
   <listitem>
    <para>
-    simpler handling of the single hierararchy
+    simpler handling of the single hierarchy
    </para>
   </listitem>
  </itemizedlist>
@@ -108,8 +107,8 @@
    <para>
    To enable the unified control group hierarchy, append
    <option>systemd.unified_cgroup_hierarchy=1</option> as a kernel command
-   line parameter to the &grub; boot loader. (Refer to
-   <xref linkend="cha-grub2"/> for more details about configuring &grub;.)
+   line parameter to the &grub; boot loader. For more details about configuring &grub;, refer to
+   <xref linkend="cha-grub2"/>.
   </para>
  </sect1>
 
@@ -122,9 +121,9 @@
   </para>
 
   <para>
-   The accounting has relatively small but non-zero overhead, whose impact
-   depends on the workload. Activating accounting for one unit will also
-   implicitly activate it for all units in the same slice, and for all its
+   The accounting has comparatively small but non-zero overhead, whose impact
+   depends on the workload. Activating accounting for one unit also
+   implicitly activates it for all units in the same slice, and for all its
    parent slices, and the units contained in them.
   </para>
 
@@ -215,7 +214,7 @@ TasksMax=infinity
 DefaultTasksMax=infinity</screen>
    <para>
     <literal>infinity</literal> means having no limit. It is not a requirement
-    to change the default, but setting some limits may help to prevent system
+    to change the default, but setting certain limits may help to prevent system
     crashes from runaway processes.
    </para>
   </sect2>
@@ -293,7 +292,7 @@ DefaultTasksMax=256
   <sect2>
    <title>Default <literal>TasksMax</literal> limit on users</title>
    <para>
-    The default limit on users should be fairly high, because user sessions
+    The default limit on users should be high, because user sessions
     need more resources. Set your own default for any user by creating a new
     file, for example
     <filename>/etc/systemd/system/user-.slice.d/40-user-taskmask.conf</filename>.
@@ -320,7 +319,7 @@ TasksMax=16284
    <para>
     How do you know what values to use? This varies according to your
     workloads, system resources, and other resource configurations. When your
-    <literal>TasksMax</literal> value is too low, you will see error messages
+    <literal>TasksMax</literal> value is too low, you may see error messages
     such as <emphasis>Failed to fork (Resources temporarily
     unavailable)</emphasis>, <emphasis>Can't create thread to handle new
     connection</emphasis>, and <emphasis>Error: Function call 'fork' failed
@@ -402,7 +401,7 @@ The throttling policy is implemented higher in the stack, therefore it
 does not require any additional adjustments.
 The proportional I/O control policies have two different implementations:
 the BFQ controller, and the cost-based model.
-We describe the BFQ controller here. In order to exert its proportional
+We describe the BFQ controller here. To exert its proportional
 implementation for a particular device, we must make sure that BFQ is the
 chosen scheduler. Check the current scheduler:
 </para>
@@ -418,9 +417,8 @@ Switch the scheduler to BFQ:
 </screen>
 <para>
 You must specify the disk device (not a partition). The
-optimal way to set this attribute is a udev rule specific to the device
-(note that &productname; ships udev rules that already enable BFQ for rotational
-disk drives).
+optimal way to set this attribute is a udev rule specific to the device. &productname; ships udev
+rules that already enable BFQ for rotational disk drives.
 </para>
 </sect3>
 
@@ -444,7 +442,7 @@ r
 </screen>
 <para>
 I/O is originating only from cgroups c and b. Even though c has a higher
-weight, it will be treated with lower priority because it is level-competing
+weight, it is treated with lower priority because it is level-competing
 with b.
 </para>
 </sect3>
@@ -476,7 +474,7 @@ example:
 <title>I/O control behavior and setting expectations</title>
 <para>
  The following list items describe I/O control behavior, and what you
- should expect under various conditions.
+ should expect under different conditions.
 </para>
 <itemizedlist>
 <listitem>
@@ -485,7 +483,7 @@ I/O control works best for direct I/O operations (bypassing page cache),
 the situations where the actual I/O is decoupled from the caller (typically
 writeback via page cache) may manifest variously. For example, delayed I/O
 control or even no observed I/O control (consider little bursts or competing
-workloads that happen to never "meet", submitting I/O at the same time, and
+workloads that happen to never <quote>meet,</quote> submitting I/O at the same time, and
 saturating the bandwidth). For these reasons, the resulting ratio of
 I/O throughputs does not strictly follow the ratio of configured weights.
 </para>
@@ -530,7 +528,7 @@ each other (but responsible resource design perhaps avoids that).
 <para>
 The I/O device bandwidth is not the only shared resource on the I/O path.
 Global file system structures are involved, which is relevant
-when I/O control is meant to guarantee certain bandwidth; it will not, and
+when I/O control is meant to guarantee certain bandwidth; it does not, and
 it may even lead to priority inversion (prioritized cgroup waiting for a
 transaction of slower cgroup).
 </para>
@@ -539,7 +537,7 @@ transaction of slower cgroup).
 <para>
 So far, we have been discussing only explicit I/O of file system data, but
 swap-in and swap-out can also be controlled. Although if such a need
-arises, it usually points out to improperly provisioned memory (or memory limits).
+arises, it points out to improperly provisioned memory (or memory limits).
 </para>
 </listitem>
 </itemizedlist>

xml/tuning_how.xml

@@ -19,7 +19,7 @@
     and provides means to solve these problems. Before you start tuning your
     system, you should make sure you have ruled out common problems and have
     found the cause for the problem. You should also have a detailed plan on
-    how to tune the system, because applying random tuning tips often will
+    how to tune the system, because applying random tuning tips does
     not help and could make things worse.
    </para>
       </abstract>
@@ -62,7 +62,7 @@
   </step>
   <step>
    <para>
-    Identify the subsystem(s) where the application is spending the most
+    Identify the subsystems where the application is spending the most
     time.
    </para>
   </step>
@@ -106,7 +106,7 @@
    Before starting to tuning a system, try to describe the problem as
    exactly as possible. A statement like <quote>The system is slow!</quote>
    is not a helpful problem description. For example, it could make a
-   difference whether the system speed needs to be improved in general or
+   difference whether the system speed needs to be generally improved, or
    only at peak times.
   </para>
 
@@ -115,8 +115,8 @@
    otherwise you cannot verify if the tuning was a success or
    not. You should always be able to compare <quote>before</quote> and
    <quote>after</quote>. Which metrics to use depends on the scenario or
-   application you are looking into. Relevant Web server metrics, for
-   example, could be expressed in terms of:
+   application you are looking into. For example, relevant Web server metrics could be expressed in
+   terms of the following:
   </para>
 
   <variablelist>
@@ -140,7 +140,7 @@
     <term>Active users</term>
     <listitem>
      <para>
-      The maximum number of users that can be downloading pages while still
+      The maximum number of users that can download pages while still
       receiving pages within an acceptable latency
      </para>
     </listitem>
@@ -152,7 +152,7 @@
 
   <para>
    A performance problem often is caused by network or hardware problems,
-   bugs, or configuration issues. Make sure to rule out problems such as the
+   bugs or configuration issues. Make sure to rule out problems such as the
    ones listed below before attempting to tune your system:
   </para>
 
@@ -207,7 +207,7 @@
   <title>Finding the bottleneck</title>
 
   <para>
-   Finding the bottleneck very often is the hardest part when tuning a
+   Finding the bottleneck is the hardest part when tuning a
    system. &productname; offers many tools to help you with this task.
    See <xref linkend="part-tuning-monitoring"/> for detailed information on
    general system monitoring applications and log file analysis. If the
@@ -220,7 +220,7 @@
    Once you have collected the data, it needs to be analyzed. First, inspect
    if the server's hardware (memory, CPU, bus) and its I/O capacities (disk,
    network) are sufficient. If these basic conditions are met, the system
-   might benefit from tuning.
+   can benefit from tuning.
   </para>
  </sect1>
  <sect1 xml:id="sec-tuning-basics-tuning">
@@ -233,7 +233,7 @@
    impact. Each tuning activity should be measured over a sufficient time
    period to ensure you can do an analysis based on significant
    data. If you cannot measure a positive effect, do not make the change
-   permanent. Chances are that it might have a negative effect in the
+   permanent. Chances are that it can have a negative effect in the
    future.
   </para>
  </sect1>