lkml.org 
[lkml]   [2004]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [from the cache]
©2003-2011 Jasper Spaans