Messages in this thread | | | Date | Fri, 10 Dec 2004 22:24:51 +0100 | From | Ingo Molnar <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15 |
| |
* Mark_H_Johnson@raytheon.com <Mark_H_Johnson@raytheon.com> wrote:
> [...] I also had several cases where I "triggered" a trace but no > output - I assume those are related symptoms. For example: > > # ./cpu_delay 0.000100 > Delay limit set to 0.00010000 seconds > calibrating loop .... > time diff= 0.504598 or 396354830 loops/sec. > Trace activated with 0.000100 second delay. > Trace triggered with 0.000102 second delay. [not recorded] > Trace activated with 0.000100 second delay. > Trace triggered with 0.000164 second delay. [not recorded]
is the userspace delay measurement nested inside the kernel-based method? I.e. is it something like:
gettimeofday(0,1); timestamp1 = cycles();
... loop some ...
timestamp2 = cycles(); gettimeofday(0,0);
and do you get 'unreported' latencies in such a case too? If yes then that would indeed indicate a tracer bug. But if the measurement is done like this:
gettimeofday(0,1); timestamp1 = cycles();
... loop some ...
gettimeofday(0,0); // [1] timestamp2 = cycles(); // [2]
then a delay could get inbetween [1] and [2].
OTOH if the 'loop some' time is long enough then the [1]-[2] window is too small to be significant statistically, while your logs show a near 50% 'miss rate'.
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/
| |