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

[Gedare Bloom]

On Tue, Mar 11, 2014 at 4:04 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> 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;
>
>

Yes, this is much better.

>>
>>> +  /**
>>> +   * @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;
>
>

Thanks for clarifying.

>>
>>> +  /**
>>> +   * @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.
>  */
>
> [...]
>

Great,
Gedare

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