[lkml]   [1999]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Scheduling latencies news: less RAM = less latency

On Sat, 31 Jul 1999, Linus Torvalds wrote:

> 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:53    [W:0.045 / U:11.940 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site