Messages in this thread | | | Date | Sat, 31 Jul 1999 22:10:03 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: 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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |