Running tuned-adm without arguments using Python 3 results in
a traceback. This is because in this case parse_args does not
exit with a usage message in Python 3 and the 'action' option
is then undefined. So let's check for this case and print the
usage message ourselves. There may be a better solution to this,
but I wasn't able to come up with anything in a reasonable amount
of time.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
As noted in the bugzilla ticket
https://bugzilla.redhat.com/show_bug.cgi?id=1554851
The QEMU I/O thread can interrupt the time measurement
of the timer. To avoid this problem, only
pin the vCPU thread.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Reviewed-and-Tested-by: Luiz Capitulino <lcapitulino@redhat.com>
v2:
- Use unix sockets (Luiz)
- Proper numeric output (Luiz)
In the cpu-partitioning profile, IRQ affinity change is already done
as part of the 'isolated_cores' option of the scheduler plugin, so
calling defirqaffinity is, at best, redundant. So let's remove the call.
In the realtime* profiles, it's essentially the same, except that tuna
was used instead of isolated_cores. So let's use built-in functionality
instead of tuna and drop calls to defirqaffinity.
Resolves: rhbz#1590937
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Previously the irqbalance config was not modified if setting the affinity
of at least one IRQ failed. That does not make much sense to me - it can
result in irqbalance assigning isolated CPUs to IRQs, even if it can be
prevented.
Even if affinity cannot be changed for any of the present IRQs,
hypothetically it can happen (I think) that new hardware is hotplugged,
and the affinity of its IRQ can be changed. So let's always modify the
irqbalance config for good measure.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The EIO errno is returned by kernel/irq/proc.c:write_irq_affinity()
if and only if changing SMP affinity of a particular IRQ is not
supported (at least on Linux 3.10 and 4.18). So let's log a failure
to change the affinity only as DEBUG if we get EIO and we are not in
the process of restoring the affinity, because the failure is expected
and there's nothing we can do about it. If we're restoring, use ERROR
log level, so that the user is informed that we failed to restore
the affinity to its original state (this should not happen though).
Other errnos can be significant, so always log them as ERROR.
Resolves: rhbz#1590937
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The code was completely broken. Jaroslav and I think the purpose
of the code was to check that the files
/sys/module/kvm/parameters/kvmclock_periodic_sync
/sys/module/kvm_intel/parameters/ple_gap
contain "0", which we think is the (at least intended) result of
profiles/functions:setup_kvm_mod_low_latency(). So I'm fixing it
to do that.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Fix checking that the list of CPUs specified in isolated_cores
contains only CPUs that are present on the machine.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
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>
