Difference between revisions of "Scheduler Parameters"

Revision as of 19:53, 21 October 2011

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.

(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)