[PATCH 03/11] sapi: Add per-CPU profiling application level data

[Sebastian Huber]

On 2014-03-10 16:44, Gedare Bloom wrote:
> On Mon, Mar 10, 2014 at 9:28 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>> ---
>>   cpukit/sapi/include/rtems/profiling.h              |   83 ++++++++++++++++++
>>   cpukit/sapi/src/profilingreportxml.c               |   89 ++++++++++++++++++++
>>   testsuites/sptests/spprofiling01/spprofiling01.scn |   10 ++-
>>   3 files changed, 181 insertions(+), 1 deletions(-)
>>
>> diff --git a/cpukit/sapi/include/rtems/profiling.h b/cpukit/sapi/include/rtems/profiling.h
>> index ee56a03..ecb3ff7 100644
>> --- a/cpukit/sapi/include/rtems/profiling.h
>> +++ b/cpukit/sapi/include/rtems/profiling.h
>> @@ -61,6 +61,12 @@ extern "C" {
>>    * @brief Type of profiling data.
>>    */
>>   typedef enum {
>> +  /**
>> +   * @brief Type of per-CPU profiling data.
>> +   *
>> +   * @see rtems_profiling_per_cpu.
>> +   */
>> +  RTEMS_PROFILING_PER_CPU
>>   } rtems_profiling_type;
>>
>>   /**
>> @@ -74,6 +80,78 @@ typedef struct {
>>   } rtems_profiling_header;
>>
>>   /**
>> + * @brief Per-CPU profiling data.
>> + */
>> +typedef struct {
>> +  /**
>> +   * @brief The profiling data header.
>> +   */
>> +  rtems_profiling_header header;
>> +
>> +  /**
>> +   * @brief The processor index of this profiling data.
>> +   */
>> +  uint32_t processor_index;
>> +
>> +  /**
>> +   * @brief The maximum time of disabled thread dispatching in nanoseconds.
>> +   */
>> +  uint32_t max_thread_dispatch_disabled_time;
>> +
> I suppose it is safe to assume the max is less than 4 seconds...

Yes.

>
>> +  /**
>> +   * @brief Count of times when the thread dispatch disable level changes from
>> +   * zero to one in thread context.
>> +   *
>> +   * This value may overflow.
>> +   */
>> +  uint64_t thread_dispatch_disabled_count;
>> +
>> +  /**
>> +   * @brief Total time of disabled thread dispatching in nanoseconds.
>> +   *
>> +   * The average time of disabled thread dispatching is the total time of
>> +   * disabled thread dispatching divided by the thread dispatch disabled
>> +   * count.
>> +   *
>> +   * This value may overflow.
>> +   */
>> +  uint64_t total_thread_dispatch_disabled_time;
>> +
> Is there any option to check for such overflow conditions? It might be
> good to state the conditions under which the overflow may occur. I
> don't think overflow is likely for most systems...

If you have an 1GHz CPU counter, then this can overflow in 58 years.  Since the 
system shouldn't spend most of the time in critical sections this is much 
longer.  This comment is just a warning.

>
>> +  /**
>> +   * @brief The maximum interrupt delay in nanoseconds if supported by the
>> +   * hardware.
>> +   */
>> +  uint32_t max_interrupt_delay;
>> +
> How does an application tell whether the HW supports this one or not?
> What does this measure exactly? My guess would be the time from the
> interrupt signal arriving to the jump to ISR, thus giving the maximum
> worst-case interrupt response time.

Ok, I try to clarify this.  Your guess is right.  What about:

   /**
    * @brief The maximum interrupt delay in nanoseconds if supported by the
    * hardware.
    *
    * The interrupt delay is the time interval from the recognition of an
    * interrupt signal by the hardware up to the execution start of the
    * corresponding high-level handler.  The interrupt delay is the main
    * contributor to the interrupt latency.  To measure this time hardware
    * support is required.  A time stamp unit must capture the interrupt signal
    * recognition time.  If no hardware support is available, then this field
    * will have a constant value of zero.
    */
   uint32_t max_interrupt_delay;

>
>> +  /**
>> +   * @brief The maximum time spent to process a single sequence of nested
>> +   * interrupts in nanoseconds.
>> +   *
>> +   * This is the time interval between the change of the interrupt nest level
>> +   * from zero to one and the change back from one to zero.
>> +   */
>> +  uint32_t max_interrupt_time;
>> +
>
> Is this the measured worst-case execution time for ISRs ?

   /**
    * @brief The maximum time spent to process a single sequence of nested
    * interrupts in nanoseconds.
    *
    * This is the time interval between the change of the interrupt nest level
    * from zero to one and the change back from one to zero.  It is the measured
    * worst-case execution time of interrupt service routines.  Please note that
    * in case of nested interrupts this time includes the combined execution
    * time and not the maximum time of an individual interrupt service routine.
    */
   uint32_t max_interrupt_time;

>
>> +  /**
>> +   * @brief Count of times when the interrupt nest level changes from zero to
>> +   * one.
>> +   *
>> +   * This value may overflow.
>> +   */
>> +  uint64_t interrupt_count;
>> +
> Can this value realistically overflow?

No.

>
>> +  /**
>> +   * @brief Total time of interrupt processing in nanoseconds.
>> +   *
>> +   * The average time of interrupt processing is the total time of interrupt
>> +   * processing divided by the interrupt count.
>> +   *
>> +   * This value may overflow.
>> +   */
>> +  uint64_t total_interrupt_time;
> Again, it might be good to state the conditions under which the
> overflow may occur.

Ok:

/**
  * @brief Per-CPU profiling data.
  *
  * Theoretically all values in this structure can overflow, but the integer
  * types are chosen so that they cannot overflow in practice.  On systems with
  * a 1GHz CPU counter, the 64-bit integers can overflow in about 58 years.
  * Since the system should not spend most of the time in critical sections the
  * actual system run-time is much longer.  Several other counters in the system
  * will overflow before we get a problem in the profiling area.
  */

[...]


-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.