1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
|
The Debian Package kernel-patch-2.4-lowlatency
----------------------------------------------
Here is Andrew Morton's low latency patch. It works in conjuction with
Robert Love's pre-emptive kernel patch, available in the
kernel-patch-2.4-preempt package.
If you have compiled with the "Control low lateency with sysctl"
option, you may want to append the following line to /etc/sysctl.conf.
kernel.lowlatency = 1
-- Simon Law <sfllaw@debian.org> Tue, 16 Sep 2003 16:38:37 -0400
------------------------------------------------------------------------
I have blatently copied the following notes from Andrew Morton's site:
http://www.zip.com.au/~akpm/linux/schedlat.html
THE NOTE BELOW
Low-latency is enabled via the "Processor Type and Features"
menu or x86
In the 2.4.1 patch, Low-latency was removed from the config for
other architectures. It should work OK, but I can't test it.
Drop me a note if you want to experiment with this.
There is a new configuration option "Control low latency with
sysctl". If you enable this, you can turn the low-latency
capability on and off with /proc/sys/kernel/lowlatency. The
default value is zero - low-latency disabled.
DON'T DO THAT!
There are a few things you can do to your Linux system which
will simply kill its scheduling latency. This section describes
those things as we discover them. So far, none of these are
show-stoppers - it is feasible to setup your system and it
software so these things don't happen.
* Avoid scrolling the fb console. Pavel says:
With fbcon on machine with loaded PCI bus (usb modem), N
can be ~500 milliseconds, even more with really full
screen. You know, fbcon is running with interrupts
disabled.
* Don't run hdparm. It chews 50 milliseconds.
* Don't use blkdev_close(). This function can consume tens of
milliseconds. It's used by LILO to write to the raw block
device.
* Don't switch consoles. The console driver can block
interrupts for a millisecond or so.
If you observe all the above, you should be able to achieve
consistent worse-case scheduling latencies of 0.5 milliseconds
on a 500MHz machine.
If something goes wrong and you start seeing scheduling
latencies, please try to investigate the source using the above
tools (mainly rtc_debug and amlat) and let me know what you're
doing to cause this.
[Simon: Andrew provides these tools on the page this text was
copied from.]
|
