This allows the user to adjust the queue count for each
network device.
Also add check_net_queue_count built-in function.
The functions check if the user has specified any
queue count value or not. If no value is passed the function
returns the number of housekeeping CPUs as the queue count.
Resolves: rhbz#1846767
Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
plugin_net instances can now be given a new 'channels' option with
the following values (see ethtool(8) for their meaning):
rx N
tx N
other N
combined N
The syntax is the same as the syntax for 'rings', 'coalesce' and
other parameters introduced previously.
Example:
[net]
channels=combined 16
Since a network device either supports rx/tx or combined queue
mode. This patch automatically adjusts the parameters based on the
mode supported by the device as long as a valid configuration is
requested.
Resolves: rhbz#1846767
Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
Currently the 92-tuned.install kernel-install plugin modifies all
BLS snippets that match the KERNEL_INSTALL_MACHINE_ID passed to
the script.
This makes sense for the system managed entries but it conflicts
with entries that are managed by the boom boot manager: boom will
propagate these options if they are present when the entry is set
up, but the files should not be modified outside boom's control
since this will cause the boom boot identifier to change.
Boom boot entries include the boot_id in the file name pattern:
%{machine_id}-%{boot_id}-%{version}.conf
Compared to the system managed entries which use:
%{machine_id}-%{version}.conf
Modify 92-tuned.install to skip this change for files that match
the boom naming convention.
Rather than rely on the presence of '-' (which may appear in some
kernel builds, especially custom or debug kernels), use a regular
expression to match the 7-character or greater SHA1 hash that
appears in boom BLS snippet file names and the remaining structure
of the file name.
A paired change is made to the tuned.spec %postun script to apply
the same scope to the logic that reverts these changes on removal.
This gives the correct behaviour for me of continuing to add the
$tuned_... references to the system managed entries where needed,
but without causing unexpected changes to the boom boot entries.
The spec file also correctly reverts the change for the same set
of entries when %postun is executed.
Signed-off-by: Bryn M. Reeves <bmr@redhat.com>
The option 'default_irq_smp_affinity' affects what will be written to the
/proc/irq/default_smp_affinity. The option supports the following values:
calc:
Content of the /proc/irq/default_smp_affinity will be calculated from
the 'isolated_cores'. Non-isolated cores are calculated as an inversion
of the 'isolated_cores'. Then the intersection of the non-isolated cores
and the previous content of the /proc/irq/default_smp_affinity is
written to the /proc/irq/default_smp_affinity. If the intersection is
empty set, then just the non-isolated cores are written to the
/proc/irq/default_smp_affinity. This behavior is the default if
option 'default_irq_smp_affinity' is not specified.
ignore:
The /proc/irq/default_smp_affinity is not touched by Tuned.
cpulist like e.g. '1,3-4':
The cpulist is unpacked and directly written to the
/proc/irq/default_smp_affinity
Examples:
[scheduler]
isolated_cores = 1, 2
default_irq_smp_affinity = calc
[scheduler]
isolated_cores = 1, 2
default_irq_smp_affinity = ignore
[scheduler]
isolated_cores = 1, 3
default_irq_smp_affinity = 2, 4
Resolves: rhbz#1896348
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
The service plugin can handle sysvinit, sysv-rc, openrc, systemd.
Syntax is the following:
[service]
service.sendmail = start,enable,file:${i:PROFILE_DIR}/tuned-sendmail.conf
'start' means to start the service, 'stop' to stop, 'enable' to enable,
'disable' to disable, file:FILE is the overlay configuration file
that will be installed for the service. Multiple directives can be
separated by comma ',' or semicolon ';'. If the directives are
conflicting, the last one will be used. The internal variable
${i:PROFILE_DIR} points to the directory from which the profile is
loaded.
The service plugin supports configuration overlays only for the systemd,
for other init systems this directive is ignored. The configuration
overlay files are copied to the /etc/systemd/system/SERVICE_NAME.service.d/
directories. Upon unloading if the directory is empty, it's removed.
With systemd, the 'start' directive is implemented by 'restart' in order
to allow loading of the service configuration file overlay.
With init systems other than systemd, it works only with the current runlevel.
Resolves: rhbz#1869991
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Like the cpu-partitioning profile, exclude all 'pmd' threads
to avoid repinning ovs-vswitchd pmds.
Resolves: rhbz#1861767
Signed-off-by: Christophe Fontaine <cfontain@redhat.com>
Add plugin to open a socket with SOF_TIMESTAMPING_OPT_TX_SWHW.
This is for avoiding interruptions due to static key IPIs due
to opening socket with timestamping enabled (by opening a
socket ourselves the static key is kept enabled).
Thanks to Jiri Mencak for porting the C code to Python.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Without LAPIC tuning we do not need qemu-kvm-tools-rhev and
tuned-profiles-nfv-host-bin requirements.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
The LAPIC advancement improvement is minimal (3 or 4 us) and its
calculation has shown to be problematic under certain
scenarios (for example if qemu-kvm is not installed).
Remove it.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
E.g. Ubuntu uses /bin/mktemp, while e.g. Fedora uses /usr/bin/mktemp.
There is probably no need to hardcode the path, so rely on the system path.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
It turned out that disablement of the numa_balancing could result in
upto 20% performance drop on some loads.
Related: rhbz#1746957
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Fixes#232
sysfs exports virtual dmi device structs which provides chassis type in numeric form, it should be available in all RHEL6+, so I used it as primary source (not much overhead).
If for some reasons it couldn't be read, dmidecode output will be parsed instead. Removed any references to python-dmidecode module.
chassis type is gathered only once, and only one intance of ProfileRecommender will be created (in daemon).
Signed-off-by: Michal Bajer <outSH@users.noreply.github.com>
Fix whitespace and other minor issues in solution for #232
Signed-off-by: Michal Bajer <outSH@users.noreply.github.com>
Currently, the post-loaded profile is shown only among regular active
profiles. For example:
Current active profile: balanced post
This is not entirely user-friendly, because the user may not know why
the post-loaded profile is there, given that they did not specify it
in a 'tuned-adm profile' command and given that it's not present in
/etc/tuned/active_profile.
To give the user a hint about this and also to make it easy to see
exactly which profile is post-loaded, we make 'tuned-adm active' show
the following:
Current active profile: balanced post
Current post-loaded profile: post
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
If Tuned is running without any profile applied (e.g. after running
'tuned-adm off'), then 'tuned-adm profile_info' crashes with the
following error:
2020-06-08 17:24:11,998 ERROR dbus.connection: Unable to set arguments (None,) according to signature 's': <class 'TypeError'>: Expected a string or unicode object
ERROR:dbus.connection:Unable to set arguments (None,) according to signature 's': <class 'TypeError'>: Expected a string or unicode object
dbus[25054]: arguments to dbus_message_get_destination() were incorrect, assertion "message != NULL" failed in file ../../dbus/dbus-message.c line 3678.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
Aborted (core dumped)
To fix it, detect that no profile is applied and print the same
message as in _action_profile_info in this case.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
This commit adds cgroup v1 support to the scheduler plugin. It seems that
cgroup v1 is the default on RHEL-8. Systemd uses it there, so we have to
start with the cgroup v1. On Fedora, systemd has been switched to the
cgroup v2 (tested on f31), but it's still possible to intermix there
with the cgroup v1. We can add cgroup v2 support later (the logic of the
extended syntax will not change).
This commit extends the syntax the following way:
[scheduler]
cgroup_mount_point=/sys/fs/cgroup/cpuset
cgroup_mount_point_init=1
cgroup_groups_init=1
cgroup_for_isolated_cores=group
cgroup.group1=2
cgroup.group2=0,2
group.ksoftirqd=0:f:2:cgroup.group1:ksoftirqd.*
ps_blacklist=ksoftirqd.*;rcuc.*;rcub.*;ktimersoftd.*
isolated_cores=1
--
Legend:
'cgroup_mount_point' is where to mount the cgroup FS or where Tuned
expects it to be mounted. If unset '/sys/fs/cgroup/cpuset' is expected.
'cgroup_groups_init' if set to '1' (the default) it means that Tuned
will create (and remove) all cgroups defined with the 'cgroup*' options.
If set to '0' (or similar boolean) the cgroups need to be preset by
some different tool or by hand.
'cgroup_mount_point_init' if set to '1' (or similar boolean) it means that
Tuned will create (and remove) the cgroup mountpoint. It implies
'cgroup_groups_init = 1'. If set to '0' (the default) the cgroups
mount point needs to be preset by some different tool or by hand.
'cgroup_for_isolated_cores' is the cgroup name used for the
'isolated_cores' functionality. For example here if the system has 4 CPUs,
'isolated_cores=1' means that all threads (except of the blacklisted ones
by the 'ps_blacklist' regexes) will be moved to the CPU cores 0,2,3. It will
be done the way that cgroup 'group' will be set to use the affinity 0,2-3
by the 'cpuset.cpus' control file) and all matching threads will be moved
to this cgroup. If 'cgroup_for_isolated_cores' is unset, classic cpuset
affinity will be used to achieve the goal.
'cgroup.CGROUP_NAME' defines affinities for arbitrary cgroups.
Even hierarchic cgroups can be used, but the hieararchy needs to be
specified in the correct order. Also Tuned doesn't do any sanity checks
here (except that it forces the cgroup to be under the mountpoint).
In the example it defines 'group1' with the affinity set to the CPU 2
and 'group2' with the affinity set to CPUs 0, 2.
'group.' its syntax has been extended, so it's now possible to use
e.g. 'cgroup.group1' instead of the hex affinity and the matching
processes will be moved to the 'group1'. It's also possible to use
cgroups which hasn't been defined by the 'cgroup.' option described
above (e.g. cgroups not managed by Tuned).
Before the usage all cgroup names are sanitized by simple algorithm:
all dots '.' are replaced by slashes '/'. It's to prevent the plugin
to write outside the mount point.
Resolves: rhbz#1784648
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
