Running the Profiler on the Two Tasks Test Code
Build and load the “two_tasks.c” code as a DKM (Downloadable Kernel Module) and either download to a running simulator target or real lab target. Start the two tasks A and B with “sp test_tasks1” in a WindShell:
Once both test tasks are running, in the “Remote Systems” winow pane, start the profiler on the Kernel tasks running on this target as follows:
The profiler will start several tasks on your target and will bring up a profile view window in Workbench that looks like this:
Now, to make this more interesting, delete the running tasks A & B as follows and then use “unld TestCode” to unload the module (should be listed if you do a “moduleShow”) so we can modify the two_tasks.c source code to adjust CPU loading.
Modify one or both of the tasks task_a and/or task_b so that you add a Fibonacci computation that will consume CPU, like this:
If we modify just task_a, the profiler will show much higher CPU consumption by task_a only as we see here:
If we modify both task_a and task_b to compute a Fibonacci sequence, leaving their priorities at low values (90 or lower in the example code), then we’ll see more equal loading from both and as above, very little idle kernel time.
If we modify both task_a and task_b to compute a Fibonacci sequence and run them at equal PRIO=90 priority, they roughly split the CPU, but not exactly.
The WindShell, the profiler tasks, Wdb, and other critical system debug and trace/profile tasks need to be able to preempt the test tasks task_a and task_b occasionally so the IDE (Integrated Development Environment) host tools can remain in contact with the target and periodically collect profile data, however, the test tasks can both be promoted to PRIO=1 and key systems tasks as shown here set to PRIO=0. Note that “tJobTask”, “tExcTask”, “tLogTask”, “tNbioLog”, “tProfileSa”, “tShell”, and “tWdb” are kept at higher priority than the PRIO=4 for task_a and task_b just so we can continue to interact with the target and debug as shown below.
Now, taking this to extreme, we can just run task_a (use delete to kill task_b), and adjust priority of tasks using taskSetPriority and taskNameToId so that task_a is PRIO=1 and only critical debug tasks have PRIO=0 as follows, and you’ll see that we can allocate over 99% of the CPU to the task under test and still run debugging tools like the profiler in less than 1% of the left-over available CPU (low interference).
Likewise, we can run SystemViewer in “Deferred Upload” mode as well with high loading like this:
So, profiler and SystemViewer are not only simple to use to trace and profile running tasks on a system, but can be used for very high loading scenarios because both tools use minimal CPU to trace and profile. This is because the data is essentially sampled into a RAM buffer and only dumped to the host system after the fact with the Deferred SystemViewer configuration and only very occasionally with the profiler (typically once per second).