Scheduler features are a debbugging mechanism which allows to tune at
run-time some (usually experimental) features of the Linux scheduler.
Let's add a proper API abstraction to easily access the list of
supported features and tune them.
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
The Linux scheduler exposes a set of tunables via /proc/sys/kernel's
attributes staring by "sched_".
Let's add a convenient API to the sched module to read and set the
values of these attributes.
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Frequencies are not considered as governor tunables by
list_governor_tunables(), so add a special case to restore userspace
frequency when using use_governor().
While at it, reword the internal "governor" variable to not clash
with the parameter of the same name.
Running some tests on a VM I hit that unexpected scenario where the
required sched_domain file is there but then read_tree_values() fails
because there are no files to read, only directories.
This does a quick check that there's actual data to be read.
We may sometime want to temporarily use another governor, and then
restore whatever governor was used previously - for instance, RT-app
calibration ([1]) needs to use the performance governor, but we don't
want this to interfere with e.g. our current experiment.
[1]: https://github.com/ARM-software/lisa/blob/master/libs/wlgen/wlgen/rta.py#L118
I used the "Arm Limited" spelling in some headers, but it seems that
didn't get caught by the copyright update script that was used for
9fd690efb303 ("Update copyrights").
This resulted in a duplicated header being inserted, although with the
"ARM Limited" spelling. Remove the previous header and use this one
instead.
Exceptions such as TargetError can sometimes be raised because of a
network issue, which is useful to distinguish from errors caused by a
missing feature for automated testing environments.
The following exceptions are introduced:
* DevlibStableError: raised when a non-transient error is encountered
* TargetStableError
* DevlibTransientError: raised when a transient error is encountered,
including timeouts.
* TargetTransientError
When there is an ambiguity on the type of exception to use, it can be
assumed that the configuration is correct, and therefore it is a
transient error, unless the function is specifically designed to probe a
property of the system. In that case, ambiguity is allowed to be lifted
by assuming a non-transient error, since we expect it to raise an
exception when that property is not met. Such ambiguous case can appear
when checking Android has booted, since we cannot know if this is a
timeout/connection issue, or an actual issue with the Android build or
configuration. Another case are the execute() methods, which can be
expected to fail on purpose. A new parameter will_succeed=False is
added, to automatically turn non transient errors into transient ones if
the caller is 100% sure that the command cannot fail unless there is an
environment issue that is outside of the scope controlled by the user.
devlib now never raises TargetError directly, but one of
TargetStableError or TargetTransientError. External code can therefore
rely on all (indirect) instances TargetError to be in either category.
Most existing uses of TargetError are replaced by TargetStableError.
In:
commit 454b9450 ("pylint fixes")
we added:
```diff
@@ -363,7 +368,7 @@ class CgroupsModule(Module):
# Get the list of the available controllers
subsys = self.list_subsystems()
- if len(subsys) == 0:
+ if subsys:
self.logger.warning('No CGroups controller available')
return
```
which changed the invariant condition to enabled the cgroup module:
the module is enabled we we can find a "non empty" list of subsystems.
Let's fix this to bail out on an empyt list.
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
The shutils run_into support assumes that we always specify a full
cgroup path starting by "/". If, by error, we specify a cgroup name
without the leading "/" we get an ambiguous message about the cgroup not
being found.
Since this already happened to me many times, let's add an explicit
check about the cgroup name parameter to better info the user about the
requirement.
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Check /sys/devices/system/cpu/cpufreq/policy0 rather than its parent
during the probe. This is to handle the edge case where cpufreq has
been enabled in the kernel, but no frequency domains have been defined
(in which case, the module should not install).
- The autoboot message in the firmware has changed; detect both the old
and the new messages.
- Depending on where exactly the boot was interrupted, either a "reboot"
or a "reset" may be required; so send both.
The tasks() function allows to get the tasks that are in a cgroup.
Filters for the tasks TID, name and cmdline have been added to the
parameters of the function such that it is possible to select the tasks
that match these patterns.
Signed-off-by: Elieva Pignat <Elieva.Pignat@arm.com>
Add a module for controlling and interacting with GPUs. The module
currently supports kgsl/adreno based GPUs. This allows for querying
and setting the governor on the GPU, as well as seeing the frequencies
at which the the GPU can can operate.
Change-Id: I02bb997b51426ddaa13e1f8da375aa4c4a0d341a
Optimize cpuidle module initialization by using the new Target.grep_values
call to get information about all idle states in a single call to the
target during module intialization, rather lazily fetching them from the
target afterwards.
Optimize hwmon module initialization by using the new Target.grep_values
call to get information about all HWMON devices in a single call to the
target.
The set() method of the CGroup class used to freeze tasks relies on
target's write_value(). Sometimes, the freezing procedure takes some
time and the call to write_value() in set() fails by reading "FREEZING"
while it expected "FROZEN". To avoid this issue, this commits introduces
a shutil call dedicated to changing the state of the freezer controller.
The current implementation of match() in the gem5stats module returns
records matching exactly the specified keys. This commit changes this
behaviour by matching keys over regular expressions, hence resulting in
a much more powerful match() implementation.
Currently, reset_origin() in the gem5stats module enables to virtually
truncate the existing dumps from the gem5 statistics file so that any
subsequent match() calls will apply only on new dumps. However, the
current implementation resets the origin of the stats file unilaterally,
without other clients knowing about it, hence leading to data being
lost.
This commits removes the reset_origin() method and provides a different
API to handle virtual truncatures in the stats file. Namely, the match()
method now takes a base_dump parameter letting clients specifiying from
which dump they want match() to apply. This feature could also be usefull
if someone wanted to add off-line processing features for statistics
files.
- Use related_cpus rather than affected_cpus inside get_domain_cpus to
return all cpus in the domain (including those online). This changes
the behavior, but old behavior was almost certainly wrong as the
method is memoized, and so the result should not be affected by
hotplug.
- Add a non-memoized get_affected_cpus() which implements the old
behavior.
Calling thermal.disable_all_zones() would raise an exception.
I've changed a few things:
* use self.zones.itervalues() in disable_all_zones to fix that exception
* renamed zone.set_mode() to zone.set_enabled()
