Column: Embedded design
The y axis shows the time occupied
by any particular “actor”, defined as any execution element such as a thread or process. When selecting one of the kernel threads, there will be a few spikes in its execution time, at approximately 350, 450 and 550 microseconds. To determine if they are of any concern, we would either need to know the timing requirements of the system or how it operates under “normal” conditions. This can be achieved through the next view, Figure 6. This graph shows a relatively large
spike in the execution time of one kernel thread, and to determine its nature the “CPU Load” can be used (Figure 7), which shows the CPU usage by different actors. It’s now clear that there’s no cause for
concern. T e CPU use for both kernel threads never exceeded 1.1%, so what we saw in the “Actor Instance” graph was simply a spike in the execution time of the green kernel thread relative to the blue kernel thread. It’s important to note that Tracealyzer
defaults to the y axis to support visible presentation of the data, which is why we don’t see the y axis capped at 100% (not much will be seen anyway!). Selecting the “lttng-sessiond” actor in
the CPU load graph captures the image in Figure 8. This process occupies 90% of the
CPU near the beginning of the trace – it’s important to note that Tracealyzer adjusted the y axis to present a meaningful view of the data. While this is substantial, it is to be expected, since the lttng userspace daemon needs to perform the necessary initialisation to capture traces. Moreover, there is not much else going on that competes for the CPU time. For comparison purposes, we can also see the CPU use of the kernel threads. The final graphic is the “Context
Switch Intensity” view (Figure 9), which allows us to confirm that the kernel driver is performing, without causing the kernel to “thrash”. It’s clear that there are no significant
context switches for any particular kernel thread relative to others. If there were any driver performance issues, then there
Figure 9: “Context Switch Intensity” view
would be significant context switches of its kernel thread. This would be due to the kernel scheduler allowing execution time to the kernel thread, then moving to another thread after some time, but then switching immediately back to my thread if it demanded execution resources. Again, the determination of whether approximately 20 context switches – as shown in Figure 9 – are acceptable depends on either the system requirements, or the measurements performed when the system is behaving “normally”. These views also allow us to see
the trace and locate “hotspots” or anomalies of interest for further analysis, especially if we’re not sure
what to look for. This is one of the main benefits of Tracealyzer, since these can be difficult to find in long traces with many thousands or even millions of events. In summary, Tracealyzer provided
numerous valuable perspectives on my driver’s execution, with each perspective providing a unique insight into the Linux system, including the kernel. When combined, these perspectives
give a holistic view of the driver to ensure there are no performance bottlenecks, and help identify the cause of any that might need further investigation. In a follow-up I’ll build my driver
and use Tracealyzer to validate its performance.
www.electronicsworld.co.uk February 2021 13 Figure 8: The “lttng-sessiond” actor in the CPU load
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44
