trace-cmd is a Linux-specific executable that is not available on other
operating systems (even on other Unixes). The option to report on target
allows acquiring text trace even if the host is not running Linux.
If the path passed into get_trace() is a directory, the collector is
supposed to use the name of the output file on target for the file on
the host. Until now however, os.path.dirname() was mistakenly called on
the target location (returning the containing directory rather than the
base name of the file).
On some systems CPUs sometimes remain idle for several seconds. If a
trace capture begins during one of these long idle periods, that CPU's
idle state is unknown (in practice it is probably in its deepest
available state from cpuidle's perspective but that can't be known for
sure).
The solution to the equivalent problem for cpufreq is to read the
current frequencies from sysfs and inject artificial cpu_frequency
events using trace_marker (see cpu_freq_trace_all_frequencies in
bin/scripts/shutils.in). However we can't read the current idle state
from sysfs.
Instead, wake up each CPU by executing the "true" command on it via
taskset.
Configuration sysfs files required by ftrace are usually accessible only by
the root user. In systems where ADB does not run as root by default, the
initialisation of the ftrace module fails.
This patch ensure that all ftrace commands are executed with root privileges.
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
This is the only info statement which is thus clobbering the "normal"
output of a client ueser for that devlib. This patch demote the logging
to debug level. The user can still log-report the output file which is also
an input parameter.
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
In general we could be interested to define a common configuration to use
across different kernels. Thus, for a given set of experiments, some
trace events can be present only on some kernels and not others.
This patch introduces a check for the availability of trace events by
ensuring that we consider only those available in the kernel in use
in the target. In case of a trace event is not supported in the target
kernel we still log a warning.
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
In general we could be interested to defined a common configuration to use
across different kernels. Thus, for a given set of experiments, some
functions can be present only on some kernels and not others.
This patch updates the check for the availability of functions to profile by
ensuring that we consider only functions available in the kernel in use
in the target. In case of a function cannot be profiled in the target kernel
we log a warning instead of raising an exception.
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Functions profiling data are reported in a set of files, one for each CPU.
This patch adds the required support to collect these data into a single
JSON formatted file. Data are collected using a shutils routing on the
target side and formatted in JSON on the host side.
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Function stats can be collected while events are accumulated into a trace.
This function adds the required support to start and stop functions
profiling across a trace collection.
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
FTrace allows to collect profiling stats for kernel functions.
This patch adds the initial support which allows to specify a list of
kernel function we would like to profile.
If a list of functions to profile is specified, for each specified function
we check for that function to be actually one of the available instrumented
functions which can be monitored by FTrace.
If a function is not supported, we throw an expection so that the user
is aware about the analysis which is going to do.
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
All ftrace generated files are present under a common base folder.
This patch updates the FtraceCollector API to exposes just the common
base folder from where all the other paths can be generated.
This is a refactoring patch which makes it easier to add further attributes.
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
The time required to fetch a trace depends not only on it time length but
also on the amount of events collected and the processing power of the
target device. This patch tries to factorise these last two components
into a 5x constant which is good enough to collect a relatively big trace
on a relatively slow device.
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
When the cpufreq module is loaded, quite likely we want to run experiments
which involve an analysis of frequencies transitions. However, if during
an experiment there are not cpu_frequency events, the generated trace
does not allows to know at which frequency the experiment has been executed.
This happens for example when we are running at constant frequency or just
because the workload is not generating a variable capacity request in the
system.
This path ensure the a "cpu_frequency" events is always generated at the
beginning and at the end of a collected trace. This support is required
for example to properly plot CPUs frequencies event when there are not
CPUFreq generated changes of OPP.
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
