How much swapspace should I allocate?Edit
Unfortunately there is not much good documentation on swapspace that is meaningful on today's hardware. As the discrepancy between ram speed and hard drive speed becomes greater each year, the old rule of 2*ramsize is just plain wrong. This was in the old days because the addr space was directly mapped into the first half of the double RAM sized swap, giving an easy translation formula; only the space >> RAM size was usuable as additional space.
Since most of your ram will be filled with cache, you don't need a huge swapspace, just enough to cope with transient periods of pressure.
The size should actually depend on the speed of your hard drive. On current drives I recommend about 256MB of swapspace (no matter how much ram you have). You could double it for a striped raid0 array of swapspace.
Scheduling policies? See also [Scheduling Policies]Edit
There are 3 special unprivileged (normal user) scheduling policies available as of 2.6.16-ck1. These can be set using the schedtools utility which has support for all of them. Additionally my toolsched scripts work as transparent wrappers for them. Note the policies are different to earlier -ck versions:
SCHED_BATCH: This is for tasks you explicitly want the cpu scheduler to know are never interactive and thus should never receive low latency treatment. Their cpu usage is dependant on their nice value. This policy is also supported by mainline now which is why there is a change of the naming/numbering scheme.
SCHED_ISO: This is for tasks you explicitly want the cpu scheduler to know are low latency real-time like tasks but you don't have root privileges for and don't wish them to ever starve the machine. They can use up to 80% of the available cpu time (on one cpu at any time). This percentage is configurable via /proc/sys/kernel/iso_cpu
SCHED_IDLEPRIO: This is for tasks you never want to use cpu if *anything* else wants cpu time. That is they only ever use spare cpu cycles that would have otherwise been idle time on the machine, and it also only uses idle disk I/O wherever possible.
More swapspace is now in use?Edit
If you are using the swap prefetch feature, one thing it does is it does not drop an entry from the swapspace once it prefetches it. The reason it does this is if the ram needs to be swapped back out again in the future, it happens for free (without disk I/O) since a copy is stored in the swap. What it does mean, though, is that the apparent swap in use will be much higher as all the copied entries will be stored there. This doesn't cost you in performance as it is very easy to drop the entries if the swapspace is required in the future. The maximum it will use is around 50% swap usage.
This patch stores a list of ram that is put to swap and if the memory subsystem is idle for a time it starts swapping the ram pages back in gently in the reverse order they went out. The idea is that when you come back to your pc after it has been idle for a while, if any applications have been swapped out they should have swapped back in quietly. It does not delete the page entries from the swap so that if there is any stress, these pages can effectively be swapped back out for free without further disk access.
Audio is such a big issue I've prepared a FAQ that I will update as needed. You can read it here: [Audio Hints]
This readjusts the way memory is evicted by lightly removing cached ram once the ram just under full capacity, if less than the "mapped watermark" percent of ram is mapped ram (ie applications). The normal system is to aggresively start scanning ram once it is completely full. The benefits of this are:
1. Allocating memory while ram is being lightly scanned is faster and cheaper than when it is being heavily scanned. 2. There is usually some free ram which tends to speed up application startup times. 3. Swapping is an unusual event instead of a common one if you have enough ram for your workload. 4. It is rare for your applications to be swapped out by file cache pressure.
The mapped watermark is configurable so a server for example might be happy to have a lower mapped percentage. The default is 66 and generally it's best left unchanged. This removes the swappiness knob entirely.
There is a server specific patch available in the patches directory. The staircase scheduler includes two special sysctl settings which allow you to optimise it's behaviour for different workloads
echo 0 > /proc/sys/kernel/interactive
will disable interactive tasks from having bursts, thus being even stricter about nice levels (suitable for non gui desktop usage or a server)
Don't use this following setting on a normal server!
echo 5000 > /proc/sys/kernel/rr_interval
makes round robin intervals much longer, delays task preemption and disables interactive mode to optimise cpu cache usage - suitable for computational intensive tasks. Any value from 1-5000 is valid, where the default for desktops chosen by the kernel ranges from 6-30. Massive values are not recommended if there is significant network traffic or other workload that requires low latencies as it has extremely bad latencies (intentionally). It is best suited to machines that do mainly cpu work and very little I/O. The highest value would be ideal for a render farm or compile farm machine.
You can set most of these in your sysctl.conf file with entries like this:
This is a complete rewrite of the scheduler policy for normal tasks built on top of the O(1) scheduler. The aim was to make a very lean simple but effective design scheduler that is intrinsically interactive and responsive instead of modifying an existing design with tweaks to make it interactive, while being absolutely fair with respect to cpu distribution and impossible to starve.
The signature for full patches can be found in the same directory as the full patch. NOTE: All kernel.org patches are signed by the kernel.org key see: Signature
Are these patches only good for desktops?Edit
There are now server specific improvements in -ck with a server specific -cks patch.
Should I use 2.4 or 2.6?Edit
I recommend everyone move to 2.6 as soon as they can. It is stable and safe enough for everyone now and should outperform 2.4 in almost any setting, especially with the -ck patches.
What happened to the 2.4 patches?Edit
All 2.4 patches now kindly maintained by Eric Hustvedt as "-lck" but the 2.4 patchset and the current -ck patchset share almost nothing now.
Take me to the new homepage of the 2.4 ck patchset