| Date | Mon, 18 Oct 2004 20:18:26 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 |
| |
* Adam Heath <adam@doogie.org> wrote:
> => dump-end timestamp 29144924 > > The kernel is jsut getting ready to start init at this point(mounting > root), so I don't know if you are really interested in this high > latency trace, but I'm sending anyways.
lets skip these for the time being, large runtime ones are the first ones to be squashed.
> However, after I reset the threshold to 50(and got a few small traces), I got > this whopper. > > (XFree86/1129/CPU#0): new 4692 us maximum-latency critical section. > => started at timestamp 358506933: <call_console_drivers+0x76/0x140> > => ended at timestamp 358511625: <finish_task_switch+0x43/0xa0> > [<c0132480>] sub_preempt_count+0x60/0x90
interesting - this could be a printk (trace) done in a critical section though. What does /proc/latency_trace tell, is it full of console code functions?
one of the best ways to avoid the console-printk-ing overhead is to do a 'dmesg -n 1' and reset the maximum back to 50. (i prefer to use the preempt_max_latency option not the preempt_thresh option.)
> ps: I've never mentioned the hardware I am running. Athlon XP 2000, 1G ram, > 460G(usable) software raid5(3*250g ide)(plus boot 120G), LVM, extra > SiliconImage UDMA133 controller(mobo can only do 100). > > I'm not certain what kind of latencies to expect with this setup. I'm > tending to ignore <100us, at least for now.
this setup shouldnt produce above-100 usec latencies with -U5 and PREEMPT_REALTIME.
Ingo - 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/
|