lkml.org 
[lkml]   [2004]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:07    [from the cache]
©2003-2011 Jasper Spaans