On Wed, 22 Jun 2005, Ingo Molnar wrote:
>
> the second trace seems to be a cross-CPU wakeup bug. It's not completely 
> clear from the trace what happened - but we measured the latency of a 
> task (wmcube-3191), where the wakeup happened on CPU#0 and wmcube-3191 
> was queued to CPU#1 which was idle at that time. The bug is that it 
> wasnt until timestamp 306us that this actually happened - and CPU#1 was 
> just idling around in default_idle() for no good reason. CPU#1 should 
> have run wmcube-3191 at around timestamp 13us.
> 
> I've uploaded the -50-07 kernel which will put some more info into the 
> traces - could you try to repeat the measurement and get similar 
> latencies? As i guess you already found out that you can always reset 
> the measurement to get a new set of traces, via:
> 
> 	echo 0 > /proc/sys/kernel/preempt_max_latency
> 
> (it's not a problem if you send me multiple latency traces, i'll figure 
> out which is the most useful one.)
> 
> 	Ingo

Hi Ingo,

Latency traces (attached) are looking a little bit better with -50-11.  
The CPU consistently seems to idle for ~200us at a time in the traces.  
Maximum wakeup latency since boot (over an hour ago) is 310us.  With
previous RT kernels, maximums would generally go over 800us.

Should I apply your SMT scheduler latency fix, or is that patch for -mm
only?

--ww