Normally, inclusion of any profile that is not found in profile
directories (/etc/tuned and /usr/lib/tuned) will fail at profile
application time.
Conditional profile loading can be useful in situations we do not
necessarily expect a certain included profile to exist. Profile
application failures are undesirable in such cases. Augment the
TuneD profile hierarchies by adding a functionality to conditionally
include a profile by prefixing its name by '-' symbol.
Example:
[main]
summary=An example TuneD profile demonstrating conditional loading
include=-profile1,profile2
In this example, the profile "profile1" is conditionally loaded/included
and no error/failure will be reported if the profile does not exist.
Then, the profile "profile2" is unconditionally loaded and errors will be
reported if it is not found in profile directories.
Signed-off-by: Jiri Mencak <jmencak@users.noreply.github.com>
The [scheduler] plug-in can be very CPU intensive, especially on the
OpenShift platform. The bug for this issue is tracked by rhbz#1921738.
Until this is fixed, work around this problem in the openshift
parent profile by adding "runtime=0" [scheduler] plug-in option.
Signed-off-by: Jiri Mencak <jmencak@users.noreply.github.com>
This option allows skipping processes belonging to the blacklisted
cgroups. It matches the regular expression against items from the
/proc/PID/cgroups. Items/lines from the /proc/PID/cgroups are separated
by commas ','. Each item consists of the:
hierarchy-ID:controller-list:cgroup-path
Example of the content on which the regular expression is run:
10:hugetlb:/,9:perf_event:/,8:blkio:/
For cgroups v2 the hierarchy-ID is 0 and the controller-list is ''.
For details see man cgroups.7. The only difference from the man
cgroups.7 is that it uses commas for separation of the items instead
of the new lines. The commas are added by the python-linux-procfs
(it's the behavior of the python-linux-procfs-0.6.3).
Multiple regular expressions can be separated by the semicolon ';'.
Examples:
[scheduler]
isolated_cores=1
cgroup_ps_blacklist=:/daemons\b
It will move all processes away from the core 1 except processes which
belongs to the cgroup '/daemons'. The '\b' is regular expression
metacharacter that matches word boundary (i.e. it matches only
'/daemons', not e.g. '/daemonset' or '/group/daemons'). In this example
we do not care about the hierarchy-ID and the controller-list.
[scheduler]
isolated_cores=1
cgroup_ps_blacklist=\b8:blkio:/,|$
In this example it skips processes belonging to the cgroup '/',
with hierarchy-ID 8 and controller-list blkio. The ',|$' is needed
because the '\b' matches word boundary and the non-alphanumeric
character '/' is not taken as a word, thus the '\b' will not match there.
[scheduler]
isolated_cores=1
cgroup_ps_blacklist=:/daemons\b;:/test\b
In this example two regular expressions are used which tries to match
'/daemons' and '/test' cgroup-path. If either matches (i.e. the OR operator),
the process is skipped (i.e. not moved away from the core 1).
Resolves: rhbz#1980715
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Currently, skip_grub_config and initrd_remove_dir options in the
bootloader plug-in are inconsistent. This commit fixes this issue.
The skip_grub_config=VALUE does not change grub configuration if VALUE
is true. However, cmdline options are still processed, and the result
is used to verify the current cmdline. Only 'y', 'yes', 't', 'true' and
'1' (case insensitive) are accepted as true values for this option.
Other values are interpreted as false.
Example:
[bootloader]
skip_grub_config=True
cmdline=+systemd.cpu_affinity=1
Signed-off-by: Jiri Mencak <jmencak@users.noreply.github.com>
This makes some changes to address systems that don't support changing
of grub configurations
* Introduce new option "skip_grub_config". When this is set, no changes to grub
config are attempted. cmdline options are still processed, and the result is
used to verify the current cmdline.
* Improve reporting on expected/found/missing cmdline arguments.
* Add "no_error = True" to the call that reads /etc/default/grub in _bls_enabled().
Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
According to the performance team measurements the sched_ tuning
should be dropped in several profiles.
Resolves: rhbz#1957829
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
New kernels (5.13 and newer) moved some sched_ and numa_ knobs from
the sysctl to the debugfs, thus add and abstract these knobs under the
scheduler plugin. With help of this abstraction it will write
the tuning to the correct place according to the kernel used.
Example:
[scheduler]
sched_migration_cost_ns = 500000
Will work on the old kernel the same way as:
[sysctl]
kernel.sched_migration_cost_ns = 500000
I.e. it will write '500000' to the:
/proc/sys/kernel/sched_migration_cost_ns
And on the new kernel it will write '500000' to the:
/sys/kernel/debug/sched/migration_cost_ns
Also updated TuneD profiles.
Resolves: rhbz#1952687
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
The 'nx_huge_pages' option, will force any executable page mapping to be
performed at 4KiB granularity and requires any existing overlapping
huge-page mapping to be also split in 4KiB chunks[1]. This is due to a HW
bug that doesn't affect our NFV use-cases.
The way a huge-page mapping is dropped is by simply deleting the EPT
entry and flushing TLB caches on all affected CPUs. Next vCPU access to
that address will trigger an EPT_VIOLATION, which will jump into the
host for it to handle the page-fault. In our specific case, this means
all isolated CPUs running oslat will hit an EPT_VIOLATION almost exactly
at the same time. Which is bad enough already, but, given our systems
might have a huge number of isolated CPUs, will also create a lot of
contention over the KVM MMU lock. This has been observed to trigger
~100us latency spikes while testing with oslat.
So let's disable the 'kvm.nx_huge_pages' module option.
[1] see kernel commit b7e8c8303ff28
Resolves: rhbz#1976825
Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
I/O APIC, one of intel's interrupt controllers, can only change the
affinity on an IRQ line during an EOI (end of interrupt)[1]. In other
words, on boot, although tuned will set a preferred IRQ affinity, it
might not be applied until the next time the interrupt is triggered.
This might be right away, or hours later while oslat or a
latency-sensitive workload is running.
To mitigate this set the 'irqaffinity='kernel command-line[2] option to
match the non-isolated CPU mask when running the realtime-virtual-*
profiles. This way we'll get the right affinity regardless of the
situation stated above.
[1] For more reference see kernel's ioapic_ack_level() function and the
IRQD_SETAFFINITY_PENDING flag.
[2] Actually, this is why irqaffinity was introduced in the first place,
see kernel commit fbf198030e0b0.
Resolves: rhbz#1974820
Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
The conditional for setting a net device parameter has
a faulty order where it can potentially try to first cast a string to int
in a wrong manner and only then check if the value is a specific integer value.
current order:
1. check if a net device has a combined channel containing 0
2. check if a net device has a combined channel containing 'n/a'
fixed order:
robust check to see if device parameter is either 0 or 'n/a'
Signed-off-by: Yanir Quinn <yquinn@redhat.com>
The original idea behind this patch is credited to
Jiří Mencák <jmencak@redhat.com>.
Resolves: rhbz#1825882
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Enable 'isolate_managed_irq' parameter by default. It is important
for -realtime systems. When it is enabled, kernel directs interrupts
to the housekeeping CPUs and thus reduces latencies for the isolated
ones.
Fixes: RHBZ#1820626
For realtime KVM host and guests it is important to use housekeeping
CPUs for processing interrupts (IRQs) and network packet transmission.
So that isolated CPUs are used for -realtime tasks assigned to them.
The 'isolate_managed_irq' and 'netdev_queue_count' variables help
to configure kernels towards this end. Users can define these
variables via tuned(8) configuration files.
Fixes: RHBZ#1817827
