#4528 closed defect (fixed)

rate monotonic: reset of CPU usage time not always detected

Reported by: Frank Kuehndel Owned by: Sebastian Huber
Priority: normal Milestone: 6.1
Component: rtems Version: 6
Severity: trivial Keywords: qualification
Cc: Blocked By:
Blocking:

Description

rtems_rate_monotonic_get_statistics() and 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 background:

The Classic API guide https://docs.rtems.org/branches/master/c-user/rate-monotonic/directives.html#rtems-rate-monotonic-get-status says for rtems_rate_monotonic_get_status():

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 _Rate_monotonic_Get_status():

  [...]
  /*
   *  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 ) )
    return false;
  [...]

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 code).

For the records:

RTEMS_VERSION    = 6.0.0
remote origin    = git://git.rtems.org/sebh/rtems.git
commit HEAD      = 1df2666ca1d73807a338e0d209ed1f42f67f00a9  (HEAD, origin/qual-43)
config.ini       =
    [arm/realview_pbx_a9_qemu]
    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) 2.36.1.20210409

Change History (5)

comment:1 Changed on Oct 12, 2021 at 6:22:08 AM by Sebastian Huber

Keywords: qualification added
Milestone: Indefinite6.1
Status: assignedaccepted

comment:2 Changed on Oct 25, 2021 at 6:00:31 AM by Sebastian Huber <sebastian.huber@…>

In 0221da5f/rtems:

rtems: Fix rate monotonic statistics

The rate monotonic period statistics were affected by
rtems_cpu_usage_reset(). The logic to detect and work around a CPU
usage reset was broken.

The Thread_Contol::cpu_time_used is changed to contain the processor
time used throughout the entire lifetime of the thread. The new member
Thread_Contol::cpu_time_used_at_last_reset is added to contain the
processor time used at the time of the last reset through
rtems_cpu_usage_reset(). This decouples the resets of the CPU usage and
the rate monotonic period statistics.

Update #4528.

comment:3 Changed on Oct 25, 2021 at 6:10:54 AM by Sebastian Huber <sebastian.huber@…>

Resolution: fixed
Status: acceptedclosed

In feb4687/rtems-docs:

c-user: rtems_rate_monotonic_get_status()

Mention that resetting the processor usage time of tasks has no impact
on the period status and statistics.

Remove no longer relevant RTEMS_NOT_DEFINED error status.

Close #4528.

comment:4 Changed on Oct 25, 2021 at 6:12:52 AM by Sebastian Huber <sebastian.huber@…>

In 24922d0/rtems:

rtems: rtems_rate_monotonic_get_status()

Mention that resetting the processor usage time of tasks has no impact
on the period status and statistics.

Remove no longer relevant RTEMS_NOT_DEFINED error status.

Update #4528.

comment:5 Changed on Oct 25, 2021 at 4:01:04 PM by Sebastian Huber <sebastian.huber@…>

In 75c133bd/rtems:

sptests/sp69: Remove test case

This error condition no longer exists.

Update #4528.

Note: See TracTickets for help on using tickets.