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    [W:0.023 / U:1.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site