Scheduler parameters /etc/vservers/<server name>/schedule should contain 6 lines:
- fill rate
- fill interval
- amount of "tokens" on start
- minimum number of tokens in token bucket
- maximum number of tokens
- 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)
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.
(Don't forget to put sched_prio or/and sched_hard flags in /etc/vservers/<vserver>/flags)
If you have set sched_prio and/or sched_hard but there is no schedule file, the following default values are used:
FillRate: 1 Interval: 4 TokensMin: 15 TokensMax: 125
(note, the default is to use pure system scheduling)