This level has the highest severity. It is meant for important messages
about situations which may require user intervention. These messages
will be shown to the user on the console when running tuned-adm (this is
implemented in a followup commit).
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Patch all existing GRUB2 config files, not just the first in order.
Based on a patch from Ryan Blakley <rblakley@redhat.com>.
Resolves: rhbz#1556990
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Properly revert affinity of processes whose affinity was changed
due to the isolated_cores setting.
Resolves: rhbz#1512295
https://bugzilla.redhat.com/show_bug.cgi?id=1512295#c19
Known regression: reverting affinity of processes started after
Tuned was started does not work as one might expect. See the following
reproducer (run on a 4 core machine):
$ mkdir /etc/tuned/test
$ cat > /etc/tuned/test/tuned.conf << EOF
[scheduler]
isolated_cores=1
EOF
$ cat > a.c << EOF
#include <unistd.h>
int main(void)
{
pause();
return 0;
}
EOF
$ gcc a.c
$ systemctl start tuned
$ ./a.out &
$ systemctl stop tuned
$ taskset -p $(pgrep a.out)
pid 9950's current affinity mask: d <<< *maybe* should be "f"
The affinity of the ./a.out process is 0xd after tuned is stopped, not
0xf as one might expect. This is because after starting tuned, first
the affinity of the shell session is set to the non-isolated cores (0xd).
Then when ./a.out starts, it inherits that affinity. That is, tuned
doesn't explicitly change affinity of the process. The affinity gets
inherited. So tuned will not change affinity of the process upon rollback,
because it hasn't ever touched that process. And currently, tuned would
not event know what the affinity should be reverted to.
It is unclear to me at this point whether we should attempt to address
this issue, or if we should leave it be. Properly fixing it would
require tracing where processes get their affinity from.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Store saved CPU affinity of processes as a bitmask rather than
a CPU list. It should be much more memory-efficient.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Do true rollback of IRQs affinity. Previously the affinity of IRQs was
set to all cores on rollback.
Related: rhbz#1512295
https://bugzilla.redhat.com/show_bug.cgi?id=1512295#c19
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Rewrite _set_rt() and _get_rt() to use schedutils instead of
command line tools.
Behaviour change: previously if the scheduling policy was set to "*"
in a profile, e.g.
[scheduler]
group.foo=0:*:1:1:a.out
then Tuned would set the scheduling policy to SCHED_OTHER on RHEL-7,
and to SCHED_RR on Fedora (at least Fedora 27). This is due to the
behaviour of the "chrt" tool. It behaved this way despite what it
says in the following commit, which says the scheduler will not be
changed if set to "*":
https://github.com/redhat-performance/tuned/commit/bf42cb9ba3c
This commit changes/fixes that, so that the scheduling policy is
in fact not changed if "*" is specified.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Set scheduler policy and affinity independently so that when reading
original state of one of the parameters fails, we can still set
the other one.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
I believe it was originally added so that errors are not logged
when we fail to set the scheduling parameters of a short-lived
process which has already disappeared. This is no longer necessary,
because we always check if the process has disappeared, and log
debug messages instead of errors if it has.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
I believe it was originally added so that errors are not logged
when we fail to set the affinity of a short-lived process which
has already disappeared. This is no longer necessary, because we
always check if the process has disappeared, and log debug messages
instead of errors if it has.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
I believe it was originally added so that errors are not logged
when we fail to read the affinity of a short-lived process which
has already disappeared. This is no longer necessary, because we
always check if the process has disappeared, and log debug messages
instead of errors if it has.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
It doesn't make much sense to have multiple instances of the scheduler
plugin, so let's make storage global for the plugin.
Later we should make Tuned report an error if the user defines multiple
instances of the scheduler plugin.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Add a new method for restoring original CPU affinity of processes
_restore_ps_affinity() and call that in _instance_init() instead of
_instance_unapply_static(). _instance_unapply_static() touches
instance._terminate, which does not yet exist at that point
(_instance_init always gets a fresh instance object).
The reason this was not a problem in the past is that the true branch
of "if len(instance._scheduler_original) > 0:" was never executed,
because instance._scheduler_original was never correctly saved
to storage. The next commit in this patch series fixes that.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Previously CPU affinity of tasks created while Tuned was running
was not correctly reverted on Tuned shutdown.
Reproducer (on a 4 core machine):
$ mkdir /etc/tuned/test
$ cat > /etc/tuned/test/tuned.conf << EOF
[scheduler]
group.foo=0⭕0:1:a.out
EOF
$ cat > a.c << EOF
#include <unistd.h>
int main(void)
{
pause();
return 0;
}
EOF
$ gcc a.c
$ systemctl start tuned
$ ./a.out &
$ systemctl stop tuned
$ taskset -p $(pgrep a.out)
pid 9950's current affinity mask: 1 <<< should be "f"
Known issue: if you run the above reproducer with the config below
after this commit is applied, the affinity of the task after stopping
tuned will be 0xd, not 0xf. This is because after starting tuned, first
the affinity of the shell session is set to the non-isolated cores (0xd).
Then when ./a.out starts, it inherits that affinity. Then when tuned tunes
the affinity of the ./a.out process, it remembers 0xd as its old affinity
rather than 0xf. It is unclear to me at this point whether we should do
anything about this issue. Properly fixing it would require tracing where
processes get their affinity from.
[scheduler]
group.foo=0⭕0:1:a.out
ps_blacklist=.*a.out.*
isolated_cores=1
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
We can now be more sure that we won't modify another operating
system's config file.
Related: rhbz#1556990
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Since Linux 4.13 the value "powersave" in the x86_energy_perf_policy
program has been renamed to "power". Let's try both values when
applying the powersave profile.
Resolves: rhbz#1508468
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Support specifying alternative Energy Performance Bias values.
The values are separated using the '|' character. For example,
if you have the following in your profile:
[cpu]
energy_perf_bias=powersave|power
then tuned will try to set EPB to 'powersave', and if that fails,
it will try to set it to 'power'.
Resolves: rhbz#1508468
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Fix verification of Energy Performance Bias on Linux 4.13+.
In Linux 4.13, the value strings accepted by the x86_energy_perf_policy
program changed.
Resolves: rhbz#1508468
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Previously verifying the value of a cpumask on systems with more than
32 cores always failed. There are two reasons for this:
1. When there are more than 32 cores, string comparison is done on the
cpu masks. This failed because the value read from sysfs contained
a line feed and was not stripped.
2. The cpumask value was not properly normalized when the value had multiple
non-zero comma separated parts, e.g. '00ffffff,80808000'
Resolves: rhbz#1528368
Catch exceptions not handled elsewhere to make applying, unapplying
and verifying a profile more robust.
Related: rhbz#1571403
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
