[RTEMS Project] #4528: rate monotonic: reset of CPU usage time not always detected
trac at rtems.org
Mon Oct 11 18:03:13 UTC 2021
#4528: rate monotonic: reset of CPU usage time not always detected
Reporter: Frank Kuehndel | Owner: Sebastian Huber
Type: defect | Status: assigned
Priority: normal | Milestone: Indefinite
Component: rtems | Version: 6
Severity: trivial | Keywords:
Blocked By: | Blocking:
`rtems_rate_monotonic_get_status()` must detect whether the used CPU time
was resetted during a period (`rtems_cpu_usage_reset()`). This is achieved
by storing the CPU usage time counter value when the period is started. To
detect whether there was a reset, the CPU usage time value from the period
start and the current value are compared. If the current value is lower
than the one from the start there was a reset.
The bug is that when the current CPU usage time value is greater than the
value at the start, a reset may still have occurred.
For example, when the period starts the used CPU time is at 1000 and 1000
is stored. Then the CPU time counter is resetted - so it is 0. Assume the
period thread does some work and the CPU usage time is at 100 when
`rtems_rate_monotonic_get_status()` is called. In this case the current
code detects the reset and returns correctly `RTEMS_NOT_DEFINED`. Yet,
when more CPU usage time passes without `rtems_rate_monotonic_period()`
being called - lets say the used CPU time is at 1200 - and
`rtems_rate_monotonic_get_status()` is called, the stored value (1000) is
smaller than the current one (1200) so the reset is not detected.
This bug has been found with a test which manipulates the time directly. I
doubt this bug is very relevant in practice. It requires that there are
periods with long intervals and much CPU load and that either the system
is shortly started or `rtems_cpu_usage_reset()` is used frequently.
The Classic API guide https://docs.rtems.org/branches/master/c-user/rate-
monotonic/directives.html#rtems-rate-monotonic-get-status says for
`RTEMS_NOT_DEFINED`: There was no status available due to a reset of the
processor time usage of the owner task of the period.
The directive `rtems_cpu_usage_reset()` sets `the_thread->cpu_time_used` 0
in line 43 of `cpukit/libmisc/cpuuse/cpuusagereset.c`.
The detection whether there was an reset or not is done in file
`cpukit/rtems/src/ratemonperiod.c` line 56 in function
* Determine cpu usage since period initiated.
_Thread_Get_CPU_time_used( owning_thread, &used );
* The cpu usage info was reset while executing. Can't
* determine a status.
if ( _Timestamp_Less_than( &used,
&the_period->cpu_usage_period_initiated ) )
The directive `rtems_rate_monotonic_get_statistics()` is affected
indirectly because collecting its data is skipped when there was a reset.
`cpukit/rtems/src/ratemonperiod.c` line 149 in function
`_Rate_monotonic_Update_statistics()` (which in turn calls the above
For the records:
RTEMS_VERSION = 6.0.0
remote origin = git://git.rtems.org/sebh/rtems.git
commit HEAD = 1df2666ca1d73807a338e0d209ed1f42f67f00a9 (HEAD,
RTEMS_DEBUG = True
RTEMS_NETWORKING = True
RTEMS_POSIX_API = True
RTEMS_SMP = True
BUILD_SAMPLES = False
BUILD_VALIDATIONTESTS = True
BUILD_UNITTESTS = True
NEWLIB_VERSION = 3.2.0
SOURCE_BUILDER = Set Builder, 6 (f12dee02d52d)
GCC_VERSION = arm-rtems6-gcc (GCC) 10.3.1 20210409 (RTEMS 6, RSB
c938bd7cbe16bd03d3b382f2d7cfee6a86aa9424, Newlib 0c0f3df)
BINUTILS_VERSION = GNU ld (GNU Binutils) 22.214.171.12410409
Ticket URL: <http://devel.rtems.org/ticket/4528>
RTEMS Project <http://www.rtems.org/>
More information about the bugs