Linux Foundation Wiki

project collaboration site

User Tools

Site Tools


realtime:documentation:howto:debugging:cyclictest:test-design:threads

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
realtime:documentation:howto:debugging:cyclictest:test-design:threads [2018/07/23 12:37]
ebugden Improve phrasing
realtime:documentation:howto:debugging:cyclictest:test-design:threads [2018/08/06 10:03] (current)
ebugden Make thread number and affinity one section
Line 1: Line 1:
-====== Cyclictest - Number of measuring threads ======+====== Cyclictest - Number ​and affinity ​of measuring threads ======
  
-The threads option (--threads) is used to specify the number of measuring threads that will be used by Cyclictest when detecting latencies. In general, it is a good idea to only have one measuring thread running on each CPU on the system. ​+The threads option (--threads) is used to specify the number of measuring threads that will be used by Cyclictest when detecting latencies. In general, it is a good idea to only have one measuring thread running on each CPU on the system. The CPUs on which the threads must execute can be specified using the affinity option (--affinity).
  
-This option is also crucial for minimizing the effect that running Cyclictest has on the observed system. When using Cyclictest, it is important make sure that only one measuring thread is intended to execute at any given time. If the intended execution times of two or more Cyclictest threads overlap then Cyclictest'​s measurements will be influenced by the latencies caused by its own measuring threads. The best way to make sure that only one measuring thread is supposed to execute at a given time is to have only one measuring thread executing on a given CPU.  +These options are crucial for minimizing the effect that running Cyclictest has on the observed system. When using Cyclictest, it is important make sure that only one measuring thread is intended to execute at any given time. If the intended execution times of two or more Cyclictest threads overlap then Cyclictest'​s measurements will be influenced by the latencies caused by its own measuring threads. The best way to make sure that only one measuring thread is supposed to execute at a given time is to have only one measuring thread executing on a given CPU. 
 + 
 +For example, if the latency of two specific CPUs is to be analyzed, specify that those CPUs should be used (with the affinity option) and also specify that two measuring threads should be used (with the threads option). To minimize Cyclictest'​s overhead in this situation, make sure that the main Cyclictest thread that collects the measurements is not running on one of the two isolated CPUs. The affinity of the main thread can be set using the //taskset// program as described in the [[realtime:​documentation:​howto:​debugging:​cyclictest:​faq#​how-can-the-influence-of-cyclictest-be-minimized-when-evaluating-latencies-on-an-isolated-set-of-cpus|Cyclictest FAQ]].
realtime/documentation/howto/debugging/cyclictest/test-design/threads.txt · Last modified: 2018/08/06 10:03 by ebugden