On Tue, Mar 11, 2014 at 4:04 AM, Sebastian Huber <sebastian.hu...@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.hu...@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.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel