lkml.org 
[lkml]   [2004]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3
    Florian Schmidt wrote:
    > On Tue, 16 Nov 2004 22:24:01 +0100
    > Ingo Molnar <mingo@elte.hu> wrote:
    >
    >
    >>great. The current release is meanwhile at -V0.7.27-10, which includes
    >>other minor updates:
    >>
    >
    >
    > Ok, this one boots fine again for me (didn't test the ones betwen my last
    > report and this one).
    >
    > I have not yet tried to get this kernel to lock up yet, but i made another
    > interesting observation:
    >
    > irq 8 at prio 98 (only irq 1 with higher prio 99). running rtc_wakeup in the
    > console (it runs SCHED_FIFO allright). Switching consoles (different text
    > consoles - not swithcing to X, though this basically produces similar
    > results) produces large jitters (around 1 ms) and occasional missed irq's
    > and piggy messages. This is completely reproducable here. The rtc histogram
    > doesn't show any large wakeup latencies.

    Just a thought. What priority are you running rtc_wakup at? If you are
    doing something like:

    schp.sched_priority = sched_get_priority_max(SCHED_FIFO); // which
    equates to a priority of 99

    Then you it is actually running at a higher priority than the rtc, and
    it won't work very well. I tend to run rtc (IRQ 8) at 99 and the
    programs accessing it at 98 which seems to work reasonably well.

    >
    > /proc/latency_trace doesn't show that high latencies either on console
    > switch:
    >
    > preemption latency trace v1.0.7 on 2.6.10-rc2-mm1-RT-V0.7.27-10
    > -------------------------------------------------------
    > latency: 63 us, entries: 22 (22) | [VP:0 KP:1 SP:1 HP:1 #CPUS:1]
    > -----------------
    > | task: IRQ 8/13, uid:0 nice:-5 policy:1 rt_prio:98
    > -----------------
    > => started at: try_to_wake_up+0x51/0x170 <c010f3a1>
    > => ended at: finish_task_switch+0x51/0xb0 <c010f911>
    > =======>
    > 5 80010004 0.000ms (+0.000ms): trace_start_sched_wakeup (try_to_wake_up)
    > 5 80010003 0.000ms (+0.000ms): (1) ((98))
    > 5 80010003 0.000ms (+0.000ms): (13) ((5))
    > 5 80010003 0.000ms (+0.000ms): try_to_wake_up (wake_up_process)
    > 5 80010003 0.000ms (+0.000ms): (0) ((1))
    > 5 80010002 0.000ms (+0.000ms): preempt_schedule (try_to_wake_up)
    > 5 80010002 0.000ms (+0.000ms): wake_up_process (redirect_hardirq)
    > 5 80010001 0.000ms (+0.000ms): preempt_schedule (__do_IRQ)
    > 5 80010001 0.000ms (+0.000ms): irq_exit (do_IRQ)
    > 5 80000002 0.000ms (+0.000ms): do_softirq (irq_exit)
    > 5 80000002 0.001ms (+0.061ms): __do_softirq (do_softirq)
    > 5 00000000 0.062ms (+0.000ms): preempt_schedule (_mmx_memcpy)
    > 5 90000000 0.062ms (+0.000ms): __schedule (preempt_schedule)
    > 5 90000000 0.062ms (+0.000ms): profile_hit (__schedule)
    > 5 90000001 0.062ms (+0.000ms): sched_clock (__schedule)
    > 13 80000002 0.062ms (+0.000ms): __switch_to (__schedule)
    > 13 80000002 0.062ms (+0.000ms): (5) ((13))
    > 13 80000002 0.062ms (+0.000ms): (98) ((1))
    > 13 80000002 0.062ms (+0.000ms): finish_task_switch (__schedule)
    > 13 80000001 0.062ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
    > 13 80000001 0.063ms (+0.003ms): (13) ((1))
    > 13 80000001 0.066ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
    >
    > I sometimes do get large values in /proc/latency_trace, but they seem to be
    > unrelated to the console switching.
    >
    > 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:08    [W:0.030 / U:60.116 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site