Tom,
trix@xxxxxxxxxx writes:
> From: Tom Rix <trix@xxxxxxxxxx>
it seems you are serious about this.
> jitterz is a program for measuring system jitter.
Aside of that not being accurate, there is neither a proper description
of the functionality nor a reasoning why this is useful and should
therefore be part of rt-tests.
> diff --git a/src/jitterz/jitterz.8 b/src/jitterz/jitterz.8
> new file mode 100644
> index 0000000..5b85640
> --- /dev/null
> +++ b/src/jitterz/jitterz.8
> @@ -0,0 +1,39 @@
> +.TH JIITERZ 8 "April 1, 2020"
> +.SH NAME
> +jitterz \- inference of stalls by looking for gaps in executing a tight loop
> +.SH SYNOPSIS
> +.B jitterz
> +.RI "<options>"
> +.SH DESCRIPTION
> +In a tight loop, measure the time between iterations.
> +If the time exceeds a theshold, increment a count in a time
> +bucket. At the end of test print out the buckets.
Jitter is the deviation from true periodicity of a periodic event.
But that's not what you are measuring here. You try to find gaps in
tight loop execution, which is something completely different.
Now again the question is what's the purpose and the value of this
measurement?
> +/* Returns clock ticks */
> +static inline uint64_t time_stamp_counter(void)
> +{
> + uint64_t ret = -1;
> +#if defined(__i386__) || defined(__x86_64__)
> + uint32_t l, h;
First of all. What's wrong with using clock_gettime() ?
> + __asm__ __volatile__("lfence");
> + __asm__ __volatile__("rdtsc" : "=a"(l), "=d"(h));
Aside of that x86-ism here, what guarantees that the CPU has lfence?
> + ret = ((uint64_t)h << 32) | l;
> +#else
> + fprintf(stderr,
> + "Add a time_stamp_counter function for your arch here %s:%d\n",
> + __FILE__, __LINE__);
This is brilliant. You know already at compile time that this can't
work, but instead of failing the build you print an error at runtime.
Thanks,
tglx
