After this change, any delayed changes of spindown are applied
as soon as the drive becomes active.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Don't run 'hdparm -S' with a lower spindown value than previously
applied, if the drive has already spun down. Executing the command
in that case makes the drive spin up with some HDDs.
Resolves https://github.com/redhat-performance/tuned/issues/1
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Log errors when applying a profile fails and also log explicitly
when we're trying to load the previously applied profile.
Resolves: rhbz#1434360
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The policy for running the 'verify_profile_ignore_missing' D-Bus method
was missing, so only root could run it. This commit adds the policy, so
that it is the same as the policy for regular 'verify_profile'.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
All units (however only device-based plugins make sense) can now be
given the 'script_pre' and 'script_post' options.
The script referenced by 'script_pre' is run before applying and
verifying static tuning and 'script_post' is run after applying and
verifying. Durring unapplying tuning, the scripts are run in reversed
order, i.e. 'script_post' before unapplying and 'script_pre' after
unapplying static tuning.
The scripts are run for each device with the following arguments.
For apply:
script.sh apply <device_name>
For verify:
script.sh verify <device_name>
For unapply (the 'profile_switch' argument is given iff we're unapplying
tuning due to a profile switch):
script.sh unapply [profile_switch] <device_name>
Additinally, instances of hotplug plugins call the scripts when a device
is added/removed with the apply/unapply argument, the same way as shown
above.
The paths to the scripts must be absolute, you can use the ${i:PROFILE_DIR}
function to fill in the profile directory. The scripts are run with
the working directory set to the directory the scripts are in.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Introduced the ${i:PROFILE_DIR} internal function, which can be used
in profiles and which expands to the directory in which the profile
configuration was found. It replaces the workdir option, which
was a bit problematic due to inheritance and the possibility
to change its value.
The ability to change the value of 'workdir' seems redundant,
as the same effect can be achieved by either specifying an absolute
path to files in unit configuration or by using a user defined
variable.
Note that now you need to specify an absolute path or use the
${i:PROFILE_DIR} functin in the initrd_add_dir and initrd_add_img
options of the bootloader plugin.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Clean up device and non-device commands it reversed order, compared to
the order in which they were applied. It makes more sense that way to me.
Related: rhbz#1246176
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
It's more descriptive to use 'tuned.non_isolcpus' kernel boot command line
parameter for dracut preudev scripts provided by Tuned than the
previously used 'tuned.cpumask'.
Related: rhbz#1395899
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
This adds 00-tuned-pre-udev.sh script into initrd image which is getting
tuned.cpumask kernel command line parameter and sets workqueue affinity
accordingly.
Resolves: rhbz#1395899
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
To remove the source directory from which the initrd image is build, the
following can be used:
[bootloader]
initrd_remove_dir = True
initrd_add_dir = /tmp/tuned-initrd.img
This will create initrd image from the /tmp/tuned-initrd.img directory and
and then it removes the tuned-initrd.img directory from the /tmp.
Related: rhbz#1414098
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Also updated the core Tuned engine to support instance.workdir to get
the directory name the profile was loaded from.
Related: rhbz#1414098
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
The bootloader plugin now supports the following options:
initrd_add_img=IMAGE
initrd_add_dir=DIR
initrd_dst_img=PATHNAME
The 'initrd_add_img' adds initrd overlay named IMAGE. The IMAGE is
added from the current profile directory. If IMAGE begins with '/' it's
taken as absolute path (e.g. initrd_add_img="/root/overlay.img").
The 'initrd_add_dir' creates initrd image from the DIR at first and then
adds the image as a overlay. The DIR is taken from the current profile
directory. If DIR begins with '/' it's taken as absolute path.
The 'initrd_dst_img' sets the name and location of the resulting initrd
image. Usually it is not needed to set it. By default the location of
initrd images is /boot and the name of the image is taken as a basename
of IMAGE or DIR. This can be overridden by 'initrd_dst_img'
Currently grub2-mkconfig doesn't support initrd overlays, so the initrd
settings are lost after 'grub2-mkconfig -o /boot/grub2/grub.cfg' is
issued. There is grub2 RFE bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1427899
Resolves: rhbz#1414098
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
The plugins were not getting cleaned up properly, so e.g. after
a profile switch instances of the Plugin class would get piled up.
This fixes commit 363d74815a.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
A new option 'devices_udev_regex' can be used in profile
configuration to specify devices to which a plugin instance
should be applied.
The option can contain a python regular expression, as specified
in https://docs.python.org/2/library/re.html#regular-expression-syntax.
The expression is effectively matched against the output of
udevadm info --query=property -n <device_path>
If the option 'devices_udev_regex' is specified, the 'devices' option
is ignored. If it is not specified, then the matching is done the same
way as previously, i.e. against 'devices'.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The _device attribute should always be the same as the union of
_assigned_devices and _free_devices, therefore it's redundant.
Its existence in my opinion brings only confusion and a potential
source of inconsistencies.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
I.e.
[myaudio]
type=audio
Will show in log as:
myaudio (audio)
and:
[audio]
Will show in log as:
audio
I.e. if the instance name and the plugin name is the same it will
not log the plugin name in braces.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Resolves: rhbz#1246172
Allow specifying order in which individual plugin instances are to be
executed.
Each instance can be given the 'instance_priority' option
in the profile configuration. The value must be an integer (it can be
negative). If no priority is specified, it is inherited from the parent
profile, or set to the default instance priority, if no parent profile
specifies the priority for that instance.
The default instance priority is by default zero, but it can be set to
a different value using the 'default_instance_priority' option in the
global configuration file.
Creating plugin instances, assigning devices to instances, initializing
instances, applying, updating and verifying tuning are all done in order
from lowest numerical instance priority to highest. Unapplying tuning and
destroying instances is done in reversed order.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
