Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]

[Florian Schmidt <mista.tapas@gmx.net>]

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