Official way to gather CPU load (IDFGH-10025)

[mickeyl]

Is your feature request related to a problem?

Getting an idea about the system load seems to be very complicated on ESP32. There are multiple approaches out there, some using vTaskGetRunTimeStats and friends, some adding custom "idle" and "monitor" tasks, but all in all nothing really works reliably.

The problem with vTaskGetRunTimeStats is that it gives an accumulated view since reboot, which is not really what we developers need. We need a "live view" of the workload, much like all other desktop and server operating systems provide -- optimally, with high and low watermarks, so that we can judge whether a given processor will be enough to handle our workload in practice.

Describe the solution you'd like.

A simple way to enable the measurement via sdkconfig plus a global function to get the percentage, and -- if possible - high and low watermarks.

Describe alternatives you've considered.

See above.

Additional context.

No response

[igrr]

Hi @mickeyl, have you tried the system/freertos/real_time_stats example bundled with ESP-IDF? It contains a print_real_time_stats function while does something similar to what you are looking for:

esp-idf/examples/system/freertos/real_time_stats/main/real_time_stats_example_main.c

Lines 30 to 44 in 56123c5

	* @brief Function to print the CPU usage of tasks over a given duration.
	*
	* This function will measure and print the CPU usage of tasks over a specified
	* number of ticks (i.e. real time stats). This is implemented by simply calling
	* uxTaskGetSystemState() twice separated by a delay, then calculating the
	* differences of task run times before and after the delay.
	*
	* @note If any tasks are added or removed during the delay, the stats of
	* those tasks will not be printed.
	* @note This function should be called from a high priority task to minimize
	* inaccuracies with delays.
	* @note When running in dual core mode, each core will correspond to 50% of
	* the run time.
	*
	* @param xTicksToWait Period of stats measurement

You can call this function once a second from some high-priority task, each time it will print the percentage of time spent in each of the tasks over the last second:

esp-idf/examples/system/freertos/real_time_stats/main/real_time_stats_example_main.c

Lines 157 to 166 in 56123c5

	//Print real time stats periodically
	while (1) {
	printf("\n\nGetting real time stats over %"PRIu32" ticks\n", STATS_TICKS);
	if (print_real_time_stats(STATS_TICKS) == ESP_OK) {
	printf("Real time stats obtained\n");
	} else {
	printf("Error getting real time stats\n");
	}
	vTaskDelay(pdMS_TO_TICKS(1000));
	}

[mickeyl]

@igrr Thanks for responding so quick. The example you're referring to is exactly what I need!

One last question before I close this issue: How much is the performance impact of enabling CONFIG_FREERTOS_GENERATE_RUN_TIME_STATS=y?

[Dazza0]

@mickeyl

One last question before I close this issue: How much is the performance impact of enabling CONFIG_FREERTOS_GENERATE_RUN_TIME_STATS=y?

Enabling CONFIG_FREERTOS_GENERATE_RUN_TIME_STATS will basically set the underlying FreeRTOS option configGENERATE_RUN_TIME_STATS to 1. The performance impact incurred by this option are:

• An extra couple of words of static memory (i.e., ulTaskSwitchedInTime and ulTotalRunTime)
• An extra word added to each task's TCB (i.e., ulRunTimeCounter)
• An extra function call and some addition operations made on every context switch (i.e., portGET_RUN_TIME_COUNTER_VALUE() call in vTaskSwitchContext()) to accumulate the run time for the task that has just switched out.

Thus, the performance overhead of simply maintain the cumulative run time of each task via the CONFIG_FREERTOS_GENERATE_RUN_TIME_STATS is usually trivial.

However, fetching the run time stats is a different case (e.g., uxTaskGetSystemState() or vTaskList()) as those functions are quite resource intensive (due to memory copies). But the performance impact of these functions depends on how often they get called.