Re: RT : 2.6.12rc5 + realtime-preempt-2.6.12-rc5-V0.7.47-15

[Ingo Molnar <mingo@elte.hu>]

* Serge Noiraud <serge.noiraud@bull.net> wrote:

> > and start a new search for a maximum latency via:
> > 
> >  echo 0 > /proc/sys/kernel/preempt_max_latency
> > 
> > and then do the X test - what is the largest latency reported in 
> > 'dmesg'? Also, please send me a (bzip2 -9 compressed, if too large) 
> > /proc/latency_trace trace output of the largest incident.
> The max latency reported are normal.

yeah. (btw., enable CONFIG_KALLSYMS to get a much more readable trace 
output)

> I have the problem with another program which mesure latencies about 
> semaphore only in X environment too.
>         
> I tried to ssh this machine from another X environment and the problem 
> does not exist. It's only on the console.

does your measurement program do any tty IO during the measurement? That 
could delay the measurement code artificially. Generally, latency 
measurement must be done very carefully (userspace and kernelspace 
alike).

E.g. rtc_wakeup uses a FIFO between two threads to isolate the 
measurement thread as much as possible. rtc_wakeup can be found at:

   http://www.affenbande.org/~tapas/wiki/index.php?rtc_wakeup

and should be run like:

  chrt -f 95 -p `pidof 'IRQ 8'`
  ./rtc_wakeup -f 1024 -t 100000

if you only trust your own measurement code then you can use a hybrid 
tracing method as well: switch the kernel's trace into 'user triggered':

  echo 1 > /proc/sys/kernel/trace_user_triggered

then you can turn tracing on in your code via a syscall hack:

	gettimeofday(0,1);

(yes - gettimeofday. Has nothing to do with tracing.) You can turn 
tracing off via:

	gettimeofday(0,0);

and the kernel will do a maximum search for you, and you should have the 
highest-latency trace available in /proc/latency_trace.

	Ingo