Normal (i.e. non-recursive) mutexes timed on the monotonic clock are
the most common form of locks used by applications. Allow people to
write more compact code by providing creation calls and static
initializers aimed at building these directly:
- evl_new_mutex(), EVL_MUTEX_INITIALIZER() for PI locks timed on the
monotonic clock.
- evl_new_mutex_any() and EVL_MUTEX_ANY_INITIALIZER() for building any
supported type of lock (normal/recursive), specifying the protocol
(PI/PP) and the base clock.
The EVL shim library mimics the behavior of the original EVL API based
on plain POSIX calls from the native *libc, which does not require the
EVL core to be enabled in the host kernel. It is useful when the
real-time guarantees delivered by the EVL core are not required for
quick prototyping or debugging application code.
This Linux-side tool is designed to echo the GPIO signals issued from
a remote board, which in turn measures the response time. The code has
been validated using a Linux-based rpi3b running gpio-echo, and a
Zephyr-based FRDMk64f board measuring the response time.
The current version of the Zephyr code is available in the zephyr/
subdirectory in patch format. This code is maintained at:
https://github.com/ldts/zephyr.git, branch evl-latency
For instance, GPIO23 can be used to receive test signals on rpi3b and
GPIO24 to respond to them.
gpio-echo is realtime capable (via EVL) or non-realtime capable
(standard Linux behaviour) - it depends on how you run it.
$ gpio-echo -n gpiochip0 -o 23 -t 24 -O -T -f
Once that process is started (and the necessary cabling is done) start
this Zephyr program, get the console and follow the instructions.
Connections:
-------------
Zephyr - FRDMk64F: Linux - rpi3b
PIN 20 (PTE-24) ---------------- PIN 16 (GPIO 23)
PIN 18 (PTE-25) ---------------- PIN 18 (GPIO 24)
Signed-off-by: Jorge Ramirez-Ortiz <jro@xenomai.org>
If /dev/cpu_dma_latency is present, we can restrict the usable C-state
the CPU may be asked to enter by writing zero to this file, and
keeping the file descriptor open for the duration of the test. This
helps in preventing PM-originated latency spikes.
This routine is mainly intended as a tool for applications to
implement LARTs, notably returning the isolation state of a CPU. This
helps in detecting when a user is about to run out-of-band work on a
non-isolated CPU.
Although a dual kernel system performs significantly better than a
native preemption system in this configuration, getting the smallest
jitter and latency figures will require running the out-of-band load
on an isolated core, so that the in-band work does not increase the
rate of cache misses for the out-of-band duties.
If -c was not given, we must run the sampler on a CPU which is part of
the out-of-band set the core is controlling since such set might have
been restricted on the kernel command line (i.e. evl.oobcpus=).
If -c was not given, we must default to the set of OOB CPUs the core
is controlling since such set might have been restricted on the kernel
command line (i.e. evl.oobcpus=).
proxy_outfd, proxy_errfd are the file descriptors of these built-in
proxies, for issuing formatted printouts without incurring switches to
the inband stage.
evl_printf() is a shorthand call formatting its argument list before
sending the resulting string through proxy_outfd.
This change allows the application to specify a fixed granularity for
writes to the target file, such as connecting the proxy with an
eventfd for instance, guaranteeing fixed-size 64bit writes to the
latter.
evl_poll() is also enabled for the proxy, with POLLOUT|POLLWRNORM
raised when the output has drained, i.e. all data have been sent to
the target file.
When the test is interrupted, we usually have some results pending in
kernel space which have been collected but not yet received via the
cross-buffer. Make sure to collect and include them in the latency
report.
Philippe Gerum