Print only log messages with log level CONSOLE by default in tuned-adm.
If we had the log level set to ERROR, people might be surprised they
suddenly get a lot of errors. The errors will probably in most cases
be harmless, e.g. a tuning is not supported on the user's system. We
should first make the logging consistent so that messages about
unsupported tunings are logged as WARN instead. Then we change tuned-adm
to print messages with level ERROR as well.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Print messages logged during a profile switch to stderr (this affects
the "profile" and "auto_profile" commands). By default messages with
log level ERROR and higher are printed. This can be changed using the
--loglevel command line option. Valid values are debug, info, warn,
error, console, none ('none' can be used to disable the log printing).
E.g.:
tuned-adm --loglevel info profile powersave
Log printing cannot be used when --async is used.
Resolves: rhbz#1538745
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Add two DBus calls:
log_capture_start(log_level, timeout)
* This will instruct Tuned to create a new log handler, which will
start writing log messages with level 'log_level' and higher to
a buffer. The log levels are standard Python log levels (e.g.
logging.INFO) or Tuned's custom log level LOG_LEVEL_CONSOLE which
is defined as 60. The handler will be destroyed after 'timeout' seconds
if contents of the buffer are not collected using log_capture_finish()
before the timeout. If 'timeout' <= 0, log messages will be collected
for as long as it takes before log_capture_finish() is called (use
with care, so that you don't fill up memory with Tuned logs). This
call returns a string ID of the log handler, a token, which should
be passed to log_capture_finish().
log_capture_finish(token)
* This will return (as a string) log messages collected by a log handler
associated with the 'token'. It will also destroy the log handler.
These calls are privileged. They can only be called by the root user or
by a user logged in on a local console (just like the change-profile DBus
calls). This restriction is meant to prevent ordinary users from forcing
Tuned to allocate an insane amount of memory for the log buffers and crash
it (or other processes). In the future we may wish to replace this
restriction with a configurable policy which determines how many (and how
big) log buffers can a user with a given UID create. We may also want to
destroy the log handler when the original caller disconnects from DBus.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Change the log level of the message about running dracut to CONSOLE.
It is an important message which should always be logged. It informs
the user that they may be required to do something.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
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>
