We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the Wiki Team page for instructions how to help or browse through our new wiki at wiki.linux-vserver.org to find the information already migrated.

Scheduler parameters /etc/vservers/<server name>/schedule should contain 6 lines:

  1. fill rate
  2. fill interval
  3. amount of "tokens" on start
  4. minimum number of tokens in token bucket
  5. maximum number of tokens
  6. dummy line

Each <fill interval> jiffies <fill rate> tokens will be put into bucket. Any tokens more than <maximum number of tokens> are spilled.

Processes will be back from "on hold" when in bucket is more than <minimum number of tokens>.

You should aim that the sum of (<fill rate> / <fill interval>) adds up to roughly the number of processors in your system. If the fill interval is too long, it might make performance erratic. Setting it as small as 1 or 2 is fine. It only actually recalculates the amount when it has to. Of course, with a fill interval of such a small value you're dishing out large chunks of the system :)

<romke> mugwump: so, wouldn't be better if fill interval be more like 10-20 ? and fill rate proportionally greater?

<mugwump> it makes little difference. Just don't go expecting smooth scheduling behaviour when it gets near HZ (100 or 1000)

(thx to mugwump)

For example:

7
32
500
200
1000
dummy

Will aim to give the context 7/32 (21.9%) of one processor. If you turned on "hard" scheduling, then if the context ran out of tokens, it would be put on hold for (200 / 7) * 32 = 928 jiffies (~1 second if HZ = 1000, ~10 seconds if HZ = 100). If you didn't turn on 'hard' scheduling, it would be run a very low priority - meaning it gets much shorter timeslices.