* Mark_H_Johnson@raytheon.com <Mark_H_Johnson@raytheon.com> wrote:

> The code does not quite match either pattern but is perhaps
> more like your second example.
> 
> For reference, the cpu_delay loop looks like this...
> 
>   t1 = mygettime();
>   for(u=0;u<(loops/1000);u++) {
>     t0 = t1;
>     if (do_a_trace) {
>       gettimeofday(0, (struct timezone*)1);
>     }
>     for (v=0;v<1000;v++)
>       k+=1;

If this is the code then on any modern CPU this is a delay on the order
of 2000 cycles - 2-3 usecs on your CPUs. The overhead of kernel entries
plus tracing is likely larger than this, so the window for the timing
race to occur ought to be pretty large.

this also means that the elapsed time of the CPU loop will be quite
variable, it will largely depend on the level and type of
tracing/debugging activated in the kernel. This could perhaps explain
the observed weirdnesses of the 'elapsed time' metric.

> [do some tests...]
> Now I'm 5 for 5 with the revised code. Odd that all the numbers
> are within about 2 or 3 usec (application measured / kernel measured).
> If it was as bad as I was measuring it, I would have expected
> one or two to be really off.

(5 for 5 means no missed latencies by the kernel tracer so far?)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/