Skip to content

Simple test to determine posix semaphore synchronization delays through the kernel.

License

Notifications You must be signed in to change notification settings

henrikau/semtest

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

34 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

#	semtest

A very hackish test for measuring the latency of (posix) semaphores on a
Linux system.

It will create a set of thread-pairs, each with its own semaphore.
Thread A (called marco) start by tagging the time, then it will up a
semaphore thread B (called polo...) is blocked on before waiting on its
own semaphore. Once polo is awoken, it will immediately up marco's
semaphore before blocking on its own semaphore. This will in turn lead
to marco being woken up. Marco will the

[ marco ]               [ polo ]
   |                       *  // block on sem_polo
   | //tag time
   | // up sem_polo        | // awoken on sem_polo
   * // block on sem_marco | // up sem_marco
                           * // block on sem_polo
   | // awoken on sem_marco
   | // tag time
   | // sleep
   < // goto beginning of loop

It is also possible to hook into the kernel ftrace subsystem by
injecting tags when a target threshold is exceeded. Combining this with
kernelshark opens up for a good way of finding issues.

## Compile

sudo apt-get install build-essentials
make

To cross-compile, run make with the CROSS_COMPILE-switch:
make CROSS_COMPILE=arch-

## Running semtest

./semtest -h
Usage:
semtest <options>

-a       --affinity      bind tasks to cores explicitly
-A       --no_affinity   do not set affinity, let the scheduler move tasks
-i ITER  --iterations    run threads for ITER iterations
-I INTER --interval      time between each semaphore-iteration
-h       --help          show this help
-n CPUS  --num_cpus      test on number of cores
-N CPUS  --ignore_cpus   ignore the (commaseparated) list of cpus, 0-indexed
-p PRIO  --priority      run with given (real-time) priority
-r       --policy_rr     use SCHED_RR instead of the default SCHED_FIFO for rt-priorities
-t LIMIT --event_trace   enable event-tracing when running, tag occurences exceeding LIMIT us


# On an idle system with 4 cores + HT (Intel E5620, CentOS 6.3, Linux
  2.6.32), you may see something like this:

./semtest -i 10000

Starting test:
Affinity:       On
Iterations:     10000
num_cpus:       8
Priority:       0
Policy:         SCHED_OTHER
Summary of 10000 iterations
P:  0, 6        Pri: 0  Max:         303        Min:           5
P:  1, 5        Pri: 0  Max:         173        Min:           4
P:  2, 7        Pri: 0  Max:         154        Min:           5
P:  3, 2        Pri: 0  Max:         348        Min:           5
P:  4, 4        Pri: 0  Max:         196        Min:           5
P:  5, 1        Pri: 0  Max:         140        Min:           5
P:  6, 0        Pri: 0  Max:         157        Min:           5
P:  7, 3        Pri: 0  Max:         151        Min:           5
(Max) Global:          348 usvg: 202.7500 us    middle: 165.000000
(Min) Global:            5 usvg: 4.8750 us      middle: 5.000000
Test took 0 hours 0 mins 11.57402 secs to complete

sudo ./semtest -i 10000 -p90

Starting test:
Affinity:       On
Iterations:     10000
num_cpus:       8
Priority:       90
Policy:         SCHED_FIFO
Summary of 10000 iterations
P:  0, 7        Pri: 90 Max:         248        Min:           3
P:  1, 6        Pri: 90 Max:         198        Min:           3
P:  2, 5        Pri: 90 Max:         183        Min:           3
P:  3, 2        Pri: 90 Max:         195        Min:           4
P:  4, 1        Pri: 90 Max:         236        Min:           4
P:  5, 4        Pri: 90 Max:         264        Min:           3
P:  6, 3        Pri: 90 Max:         201        Min:           3
P:  7, 0        Pri: 90 Max:         304        Min:           4
(Max) Global:          304 usvg: 228.6250 us    middle: 218.500000
(Min) Global:            4 usvg: 3.3750 us      middle: 3.000000
Test took 0 hours 0 mins 10.734532 secs to complete


# Correspondingly, on a loaded system (building a linux-kernel with -j <avail_cpus>

Starting test:
Affinity:       On
Iterations:     10000
num_cpus:       8
Priority:       0
Policy:         SCHED_OTHER
Summary of 10000 iterations
P:  0, 3        Pri: 0  Max:        6363        Min:           4
P:  1, 0        Pri: 0  Max:        5364        Min:           4
P:  2, 7        Pri: 0  Max:        9430        Min:           4
P:  3, 1        Pri: 0  Max:        6573        Min:           3
P:  4, 5        Pri: 0  Max:        5207        Min:           4
P:  5, 6        Pri: 0  Max:        2334        Min:           4
P:  6, 4        Pri: 0  Max:        4427        Min:           4
P:  7, 2        Pri: 0  Max:        7584        Min:           4
(Max) Global:         9430 usvg: 5910.2500 us   middle: 5863.500000
(Min) Global:            4 usvg: 3.8750 us      middle: 4.000000


sudo ./semtest -i 10000 -p90
STARTING test:
Affinity:       On
Iterations:     10000
num_cpus:       8
Priority:       90
Policy:         SCHED_FIFO
Summary of 10000 iterations
P:  0, 3        Pri: 90 Max:         542        Min:           3
P:  1, 4        Pri: 90 Max:         524        Min:           3
P:  2, 0        Pri: 90 Max:         519        Min:           3
P:  3, 5        Pri: 90 Max:         985        Min:           3
P:  4, 6        Pri: 90 Max:         531        Min:           3
P:  5, 2        Pri: 90 Max:         499        Min:           3
P:  6, 1        Pri: 90 Max:         553        Min:           3
P:  7, 7        Pri: 90 Max:         988        Min:           4
(Max) Global:          988 usvg: 642.6250 us    middle: 536.500000
(Min) Global:            4 usvg: 3.1250 us      middle: 3.000000
Test took 0 hours 0 mins 10.221402 secs to complete

About

Simple test to determine posix semaphore synchronization delays through the kernel.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published