Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→Implementation example for GNU/Linux o.s.
where the filters marked as /TraceOFF are mapped to program addresses immediately after the instrumentation.
To ensure the task switch data generated by the OS is included in the filtered trace flow, add an additional filter to the <code>__switch_to() </code> function (<code>arch/arm64/kernel/process.c</code>) where it calls the static inline <code>contextidr_thread_switch() </code> function:
<pre class="workstation-terminal">
NOTE: ‘OR Cycle task’ is optional.
This implementation was along with the software-based method were tested on the following use case:* Read/write workload to the mmc0 device was issued by using [https://github.com/stressapptest/stressapptest stressapptest] application (<code>stressapptest -s 20 -f /mnt/mmc0/file1 -f /mnt/mmc0/file2</code>) resulting in the creation of two files, along with 16 MByte each<pre class="workstation-terminal">-rw-r--r-- 1 root root 8388608 Dec 3 16:30 file1-rw-r--r-- 1 root root 8388608 Dec 3 16:30 file2</pre>* To setup <code>ftrace</code>, the following commands were run (please note that the software<code>ftrace</code> pipe is saved to a file on a different memory device i.e. <code>mmc1</code> purposely):<pre class="workstation-based methodterminal">echo 1 > /sys/kernel/debug/tracing/tracing_onecho 1 > /sys/kernel/debug/tracing/events/mmc/enableecho 20000 > /sys/kernel/debug/tracing/buffer_size_kb ; 20MB buffer sizeecho > /sys/kernel/debug/tracing/tracecat /sys/kernel/debug/tracing/trace_pipe > /home/root/prove/ftrace.txt</pre>
==== Results and comparison with the software-based method (<code>ftrace</code>) ====
The functions average duration analysis of eMMC accesses highlights the greater weight required by <code>ftrace</code>. The tests were performed under the following conditions.
Additional, more detailed charts are provided in Appendix 2, which show that using ftrace also involves a greater dispersion of the runtime durations compared to both the kernel without ftrace and the kernel instrumented only with the code for TRACE32. In particular, the functions mmc_start_request() and mmc_request_done() have a few uS constant execution time without ftrace, and show a very variable execution time with ftrace, with a maximum time up to 279uS and 285uS respectively. TBD
==== Conclusion ====
The hardware method based on TRACE32 provides the same log data as recorded by <code>ftrace</code> but with minimal changes to the kernel (a few lines in a file) and a tiny time penalty. It also does not use any additional memory (in terms of RAM and file system storage) and allows for extremely long measurement times.
The following table summarizes the advantages and disadvantages of the two considered solutions: TRACE32 vs <code>ftrace</code>.{| class==== References ===="wikitable"|+Table 3: Pros and cons!Method!Pros!Cons|-|TRACE32|* Light kernel instrumentation* No additional memory required* Long-term analysis (few hours up to over 100 days)* Can be ported to other OS's / eMMC device drivers.|* Hardware-based solution: requires a debug and trace tool + offchip-trace capable processor and target|-|<code>ftrace</code>|* Software-based solution|* Available for Linux kernel only* Heavy kernel instrumentation* Time intrusion in eMMC operations* Kernel program and data size increase* 10—100 MB of RAM required for ring buffer* Additional storage device to save the ring buffer* For each eMMC operation, <code>ftrace</code> saves roughly 876 bytes of log information.|}Please contact your eMMC vendor to obtain more information on how TRACE32 logs can be used to calculate your application lifespan. This is a very important milestone to improve the storage performance stability of your platform and for making sure the expected reliability requirements are met. TBD
==== Appendix 1: source code example ====
== Example: embedded Linux system equipped with SanDisk SDINBDG4-8G-XI1 eMMC and ext4 file system ==
TBD
= References =
* Western Digital Corporation, ''[https://link.westerndigital.com/content/dam/customer-portal/en_us/external/public/cps/p/White_Paper_Design_Considerations_v1.0.pdf Design Considerations for Embedded Products]'', 2018
* Western Digital Corporartion, ''[https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/collateral/white-paper/white-paper-automotive-workload-analysis.pdf Automotive Workload Analysis]'', September 2021
=Credits=
