On 10/25/12 14:36, Frank Rowand wrote:
> On 10/16/12 10:02, Bhavesh Davda wrote:
>> From: Bhavesh Davda <bhavesh@xxxxxxxxxx>
>>
>> Add feature to cyclictest histogram mode to track cycle counts every time a
>> sample overflows the histogram limit. This should help identify if there is a
>> timing pattern to jitters in cyclictest runs.
>>
>> Example output (with -h 10):
>> ...
>> Histogram Overflows: 00001 00007 00000 00009 00004 00007 00000 00001
>> Histogram Overflow at cycle number:
>> Thread 0: 09964
>> Thread 1: 00000 00004 00006 00008 00010 09962 11594
>> Thread 2:
>> Thread 3: 01169 04698 06782 09033 10299 11561 21517 28734 29532
>> Thread 4: 11574 11580 11583 11586
>> Thread 5: 00020 09448 13954 14954 18954 20587 24973
>> Thread 6:
>> Thread 7: 18950
>> ...
>>
>> Signed-off-by: Bhavesh Davda <bhavesh@xxxxxxxxxx>
>
> My comments up to "--" are not meant to be part of the header of the
> following patch.
>
> I am including the following patch as my review of the patch I am
> replying to. If the following patch is incorporated into the
One further thought... The histogram overflow cycle report shows
what cycle the overflow occurred in, not the actual time. Adding
the merged for all threads cycle times works because the histogram
turns off the "different intervals for different threads" option:
if (!histogram) /* same interval on CPUs */
interval += distance;
but if that ever changes then cycle is not a useful value to be
reporting.
So it seems like it would be useful to convert cycle to a time
in the report. This is something that would have to be done
anyway in post processing when trying to make use of the report.
-Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
