zephyr/tests/benchmarks/sched
Torsten Rasmussen 407b49b35c cmake: use find_package to locate Zephyr
Using find_package to locate Zephyr.

Old behavior was to use $ENV{ZEPHYR_BASE} for inclusion of boiler plate
code.

Whenever an automatic run of CMake happend by the build system / IDE
then it was required that ZEPHYR_BASE was defined.
Using ZEPHYR_BASE only to locate the Zephyr package allows CMake to
cache the base variable and thus allowing subsequent invocation even
if ZEPHYR_BASE is not set in the environment.

It also removes the risk of strange build results if a user switchs
between different Zephyr based project folders and forgetting to reset
ZEPHYR_BASE before running ninja / make.

Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-03-27 16:23:46 +01:00
..
src
CMakeLists.txt cmake: use find_package to locate Zephyr 2020-03-27 16:23:46 +01:00
README.rst
prj.conf
testcase.yaml tests: fix test identifiers 2019-12-09 15:53:44 -05:00

README.rst

Scheduler Microbenchmark
########################

This is a scheduler microbenchmark, designed to measure minimum
latencies (not scaling performance) of specific low level scheduling
primitives independent of overhead from application or API
abstractions.  It works very simply: a main thread creates a "partner"
thread at a higher priority, the partner then sleeps using
_pend_curr_irqlock().  From this initial state:

1. The main thread calls _unpend_first_thread()
2. The main thread calls _ready_thread()
3. The main thread calls k_yield()
   (the kernel switches to the partner thread)
4. The partner thread then runs and calls _pend_curr_irqlock() again
   (the kernel switches to the main thread)
5. The main thread returns from k_yield()

It then iterates this many times, reporting timestamp latencies
between each numbered step and for the whole cycle, and a running
average for all cycles run.

Note that because this involves no timer interaction (except, on some
architectures, k_cycle_get_32()), it works correctly when run in QEMU
using the -icount argument, which can produce 100% deterministic
behavior (not cycle-exact hardware simulation, but exactly N
instructions per simulated nanosecond).  You can enable this using an
environment variable (set at cmake time -- it's not enough to do this
for the subsequent make/ninja invocation, cmake needs to see the
variable itself):

    export QEMU_EXTRA_FLAGS="-icount shift=0,align=off,sleep=off"