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>
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>
I.e. one can now write:
[sysctl]
kernel.pid_max=>32768
And the kernel.pid_max will be set to 32768 if the current value is
lower or untouched if it is higher (i.e. it will be 32768 or higher).
Related: rhbz#1561005
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
It's now packaged as a standalone architecture specific package:
https://bugzilla.redhat.com/show_bug.cgi?id=1551153
Other packagers are encouraged to do the same.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
A common source of confusion within tuned is the lack of suffix
on the readahead specification in the throughput-performance
tuned.conf. This confusion is resolved, in general, by comparing
the value, for example, to blockdev or lvdisplay output. Avoid
future end-user confusion by adding a comment to the
throughput-performance tuned.conf file, explaining that the default
is in KiB, and noting the allowance of a sector suffix as well.
Signed-off-by: John Pittman <jpittman@redhat.com>
The manpage already exists, but it's empty. So, this commit actually
adds the content. Also, update the AUTHORS, FILES and SEE ALSO sections.
Resolves: rhbz#1548148
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
