Messages in this thread | | | Date | Mon, 1 Nov 2004 23:30:37 +0100 | From | Florian Schmidt <> | Subject | Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4] |
| |
took jackit-devel off cc, since it bounced anyways [too many recipients]
On Mon, 1 Nov 2004 19:46:15 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> > * Thomas Gleixner <tglx@linutronix.de> wrote: > > > > http://redhat.com/~mingo/realtime-preempt/ > > > > > > Thomas, can you confirm that this kernel fixes the irqs-off latencies? > > > (the priority loop indeed was done with irqs turned off.) > > > > The latencies are still there. I have the feeling it's worse than 0.6.2. > > what is the worst latency you can trigger with Florian's latest > rtc_wakeup code? (please re-download it, there has been a recent update)
I have fixed one or two more small issues:
1] the cpu cycles/s measurement was done while not yet running SCHED_FIFO. changed it so the rt priv is aquired beforehand
2] when one or more irq's were missed, the cycle timestamps for the last wakeup do not get used anymore for neither threshold nor max jitter reporting. It's kind of pointless to calculate jitter for a period with the fundamental requirement that no irq's be missed being violated.
3] the output file format (-o) is now
num_of_irqs_since_last_wakeup cycles_count
and basically looks like this:
1 116817809121123 1 116817810280681 1 116817811456573 1 116817812617197 1 116817813788473 1 116817814948983 1 116817816121533 ...
i suppose this data might be easily fed into a histogram producing script or something..
New download place:
http://www.affenbande.org/~tapas/wiki/index.php?rtc_wakeup
direct link (has changed. i'll remove the old tarball)
http://affenbande.org/~tapas/rtc_wakeup/rtc_wakeup.tgz
Whoever wants to be notified of new versions should mail me a reply (private), so i can drop em a line in case (lkml is hi traffic enough already)..
> > also, there are no "arbitrary load" latency guarantees with > DEADLOCK_DETECTION turned on, since we search the list of all held locks > during task-exit time - this can generate pretty bad latencies e.g. > during hackbench.
btw: i see the same build failure as Rui with lock debugging disabled. Since the lock debugging can screw timings, will this be fixed in [one of] the next version[s]?
flo - 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/
| |