Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6

["K.R. Foley" <kr@cybsft.com>]

Ingo Molnar wrote:
> * Mark_H_Johnson@raytheon.com <Mark_H_Johnson@raytheon.com> wrote:
> 
> 
>>>also, i'd like to take a look at latency traces, if you have them for
>>>this run.
>>
>>I could if I had any. The _RT run had NO latency traces > 250 usec
>>(the limit I had set for the test). The equivalent _PK run had 37 of
>>those traces. I can rerun the test with a smaller limit to get some if
>>it is really important. My build of -12 is almost done and we can see
>>what kind of repeatability / results from the all_cpus trace shows.
> 
> 
> /me is puzzled.
> 
> so all the CPU-loop delays within the -RT kernel are below 250 usecs? I
> guess i dont understand what this means then:
> 
> | The max CPU latencies in RT are worse than PK as well. The values for
> | RT range from 3.00 msec to 5.43 msec and on PK range from 1.45 msec to
> | 2.24 msec.
> 
> these come from userspace timestamping? So where userspace detects a
> delay the kernel tracer doesnt measure any?
> 
> 	Ingo
> 

Ingo,

I see something similar here also:

running realfeel with rtc histogram generates > 100 usec entries in the 
histogram but none of these are ever caught by the wakeup tracing.

IRQ 8 = 99
realfeel = 98
IRQ 0 = 97

-realfeel sets rtc up to 1024 Hz and does blocking read on rtc
-IRQ 8 hits and rtc_interrupt runs code from rtc_wake_event which sets 
last_interrupt_time then calls wake_up_interruptible which as you know 
eventually calls try_to_wake_up because it's the default_wake_function
-the blocked read then restarts after the schedule() call in rtc_read, 
right?
-then realfeel in rtc_read runs code in rtc_read_event which sets now, 
then generates histogram entry from the diff between now and 
last_interrupt_time

No wakeup latency generated from this.

I think I know why we don't get traces from this. TIF_NEED_RESCHED is 
not set for IRQ 8 at the time that it wakes up realfeel so _need_resched 
fails and trace_start_sched_wakeup doesn't actually call 
__trace_start_sched_wakeup(p)???

kr