> Somebody has bogus profiling information. There's no way it's going to
no, it really happens. With 512M RAM and a 4-way Xeon i easily got 20ms+
latencies. These latencies are rare because it's caused by prune_dcache(),
but they do happen.
some other latencies: si_meminfo() and si_swapinfo() caused a ~5msec delay
even on this box. Console switching and scrolling (when at the end of
video memory) caused ~2msec latencies. big-file truncating caused up to
20msec latencies here, and i havent even tried too hard. exit() on a big
process caused 8msec latency. fork() on a big process likewise. looking at
a big process in /proc caused similar latencies. sync_old_buffers()
introduced big latencies as well (scanning several thousands of buffers).
Some 'bad' drivers like the PS2 keyboard code caused 1-3 msec latencies as
well. All these things are fixed by my previous patch - but i'm still
working on the dcache stuff though.
the conceptual reason of these problems is that on big memory boxes there
is nothing that forces processes to sleep. This means we have to put
'scheduling controls' more explicitly to various points in the kernel. I
do not claim my patch is the correct approach, but something like that has
to be done i'm quite sure. I've been working on this in the last 3 days,
and i'm starting to reach the end of the (quite long) 'latency source'
list. The box feels much more responsive interactively even under high and
complex load.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/