The new profile sets the intel_acpi driver to passive mode to
be able to set the standard acpi governors (ondemand/userspace)
and provides more flexibility on the C-states, as it is exposed
as a new variable.
Signed-off-by: Christophe Fontaine <cfontain@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>
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>
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>
This is a minimal viable implementation of a post-loaded profile
feature. It was implemented to satisfy the needs of the
kernel_settings Ansible role.
https://github.com/linux-system-roles/kernel_settings
This feature allows us to apply a profile in a way that is
somewhat separate from the way profiles from the active_profile file
are applied. Namely, the post-loaded profile is always applied after
all the profiles from the active_profile (or more precisely, the
post-loaded profile is always put to the tail of the profile chain
when merging). Also, the post-loaded profile setting is not affected
by running 'tuned-adm profile <some profile>' - the post-loaded
profile remains applied.
The name of the post-loaded profile is stored in
/etc/tuned/post_loaded_profile.
The lack of support for multiple post-loaded profiles was more or less
an arbitrary decision. There are no problems with it, as far as I can
see. However, there is currently no use case for multiple post-loaded
profiles, so I decided to make things easier for our future selves -
it's one less thing to worry about if we need to make changes to the
profile loading logic. We can add support for multiple post-loaded
profiles anytime.
A number of other design decisions went into the
implementation. They are listed here:
https://github.com/redhat-performance/tuned/pull/272
Resolves: rhbz#1798183
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
