Getting CPU Load on a per task basis

In a real-time DSP/BIOS-based application, it is sometimes desirable to have an estimate of how the CPU load is spread among the various TSKs in the system. This article describes a utility module, THRLOAD, that can be used to obtain such an estimate. This module is provided with source code and can be downloaded as part of the RF modules from www-a.ti.com/downloads/sds_support/applications_packages/rf_modules/index.htm.

Introduction

THRLOAD has the ability to report execution time on a per task basis, along with the duration of the time period over which the data was collected. The user can then use the resulting numbers to compute the CPU load on a per task basis in their application.

THRLOAD usage requirements

The module

• Is tested and supported on C64P, C64 and C55.
• Requires DSP/BIOS 5.20 or above.
• Requires the high resolution timer to be enabled in CLK manager

When using the module, the user needs to

• Change the system wide THRLOAD_CONFIG variable to fit your system (if necessary).
  
• Include thrload.tci in your BIOS textual configuration. This script ensures THRLOAD_switchHook()to be called on each TSK switch (via HOOK configuration) to track TSK benchmark data. It also calls THRLOAD_update() periodically from an IDL thread to gather statistics. (An alternative would be to call this function periodically in a TSK, which ensures statistics are collected in a timely manner at the cost of more intrusiveness)

Configuration

Configuration of the behavior of the module is done by statically assigning creating and assigning to a global variable called THRLOAD_CONFIG. Here are the specific fields:

• tskList: For internal use only
• maxNumTsks: Max number of tasks monitored
• windowInMs: How often to call THRLOAD_update in the IDL thread when thrload.tci is included
• postProcess: User specified function to be called immediately after each update. Useful for example to compute the load as a percentage in this function.
  

Limitations

1. The per-task execution times are approximations!

• Only works with the TSK model
• HWI and SWI models not supported due to lack of ‘hooks’.
• In particular, KNL_swi is always present in the TSK model, so the numbers are only an estimate.
  
• When a SWI or a HWI is executed, their execution times are counted toward the most recently run TSK.
• A TSK switch hook function is called every time a new task is scheduled, which adds some (constant) overhead to each TSK's execution time
  

The quality of the approximation depends on load of HWI and SWI and the frequency of TSK switches.

2. The THRLOAD_update function must be called often enough in order for the high-resolution timer not to wrap (this is because it internally uses CLK_gethtime() to obtain timestamps). Otherwise the numbers reported may be erroneous. For example, for a 32-bit high-resolution timer, the THRLOAD_update function must be called at least once for every 2^32 timer ticks.

Example usage at run-time

Included with the module are several examples illustrating different usage of the THRLOAD module. In particular, there is a 'top' example that reports shows how per-task load can be reported periodically. Here is a flowchart that summarizes what happens in this example: