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

\
 
 \ /
  Last update: 2005-03-22 14:07    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site