Hi all,

testing my ltt patches over 2.6.23-i386 with latest Xenomai SVN, I found
the first noteworthy effect. First the relevant trace snippet:

...
kernel_irq_exit: 430.606359465 (/usr/src/lttng-xenomai/trace4/cpu_0), 0, 0, 
swapper, , 0, 0x0, SYSCALL
xn_nucleus_irq_enter: 430.608893573 (/usr/src/lttng-xenomai/trace4/cpu_0), 0, 
0, swapper, , 0, 0x0, SYSCALL { irq = 233 }
xn_nucleus_tbase_tick: 430.608894311 (/usr/src/lttng-xenomai/trace4/cpu_0), 0, 
0, swapper, , 0, 0x0, SYSCALL { base = "master" }
xn_nucleus_irq_exit: 430.608895290 (/usr/src/lttng-xenomai/trace4/cpu_0), 0, 0, 
swapper, , 0, 0x0, SYSCALL { irq = 233 }
xn_nucleus_irq_enter: 430.608896506 (/usr/src/lttng-xenomai/trace4/cpu_0), 0, 
0, swapper, , 0, 0x0, SYSCALL { irq = 233 }
xn_nucleus_tbase_tick: 430.608897147 (/usr/src/lttng-xenomai/trace4/cpu_0), 0, 
0, swapper, , 0, 0x0, SYSCALL { base = "master" }
xn_nucleus_timer_expire: 430.608897986 (/usr/src/lttng-xenomai/trace4/cpu_0), 
0, 0, swapper, , 0, 0x0, SYSCALL { timer = 0xf10e505c }
xn_nucleus_irq_exit: 430.608898959 (/usr/src/lttng-xenomai/trace4/cpu_0), 0, 0, 
swapper, , 0, 0x0, SYSCALL { irq = 233 }
kernel_timer_update_time: 430.608901508 (/usr/src/lttng-xenomai/trace4/cpu_0), 
0, 0, swapper, , 0, 0x0, SYSCALL { jiffies =
4294998430, xtime_sec = 1194421869, xtime_nsec = 280190150, walltomonotonic_sec 
= -1194421446, walltomonotonic_nsec = 923956260 }
xn_nucleus_timer_start: 430.608904869 (/usr/src/lttng-xenomai/trace4/cpu_0), 0, 
0, swapper, , 0, 0x0, SYSCALL { timer = 0xf10e505c, base = "master", value = 
3989600, interval = 0, mode = 0 }
kernel_softirq_entry: 430.608906715 (/usr/src/lttng-xenomai/trace4/cpu_0), 0, 
0, swapper, , 0, 0x0, SOFTIRQ { softirq_id = 1 }
kernel_timer_timeout: 430.608908237 (/usr/src/lttng-xenomai/trace4/cpu_0), 0, 
0, swapper, , 0, 0x0, SOFTIRQ { pid = 7381 }
kernel_sched_try_wakeup: 430.608909293 (/usr/src/lttng-xenomai/trace4/cpu_0), 
0, 0, swapper, , 0, 0x0, SOFTIRQ { pid = 7381, state = 1 }
kernel_timer_timeout: 430.608911261 (/usr/src/lttng-xenomai/trace4/cpu_0), 0, 
0, swapper, , 0, 0x0, SOFTIRQ { pid = 7711 }
kernel_sched_try_wakeup: 430.608912078 (/usr/src/lttng-xenomai/trace4/cpu_0), 
0, 0, swapper, , 0, 0x0, SOFTIRQ { pid = 7711, state = 1 }
kernel_timer_set: 430.608914373 (/usr/src/lttng-xenomai/trace4/cpu_0), 0, 0, 
swapper, , 0, 0x0, SOFTIRQ { expires = 31135, function = 0xc01fb88e, data = 0 }
kernel_softirq_exit: 430.608915649 (/usr/src/lttng-xenomai/trace4/cpu_0), 0, 0, 
swapper, , 0, 0x0, SYSCALL { softirq_id = 1
}
...

Xenomai is loaded at this time but not yet used. Linux runs in tickless
highres mode and obviously had programmed the host timer to fire here.
But instead of one timer IRQ (233) + its handling, we see an additional
early shot (about 3 µs too early here - the longer the timer is
programmed in advance, the larger the error gets) before the xntimer
finally expires. But at the same time, /proc/xenomai/latency reports
1000 (1 µs). So there must be more discrepancy between TSC and APIC
timebases, no? Well, nothing critical, but at least suboptimal, maybe
pointing at some hidden minor bug. Once time permits, I will check the
APIC frequency and the delay calculation on my box and compare it to
what Linux uses.

Jan



Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to