From: Sam Vilain (sam_at_vilain.net)
Date: Thu 12 Jun 2003 - 13:00:29 BST
On Thu, 12 Jun 2003 09:31, Herbert Poetzl wrote:
> do you also have some 2.4.21-rc7-ac1 version lying around *smile*?
> or is the patch-2.4.21-pre4-ac6-ctx16 the most recent?
I've merged it for you. I may even test to see whether it compiles
tonight :-)
http://vilain.net/linux/patch-2.4.21-rc7-ac1+ctx17-o1tbf.patch
Apply it to 2.4.21-rc7-ac1 with the 2.4.20ctx-17 patch (applied with
`patch -p1 -F 0' to disable fuzz).
Including the ctx17 patch, it's at:
http://vilain.net/linux/ctx/patch-2.4.21-rc7-ac1-ctx17.UNTESTED
> o As far as I understand, your approach requires the O(1)
> scheduler, but does it require anything else?
> (so would 2.4.21 with O(1) scheduler be sufficient?)
No. I've just changed the scheduler, s_context structure and the
routine that updates the timer tick. The rest is porting the ctx17
patch to the -ac kernel.
> o What are the available tuning parameters?
In sys.c:
+ /* scheduling; hard code as constants for now */
+ s_info->tokens_fr = 1;
+ s_info->tokens_div = 4;
+ s_info->tokens = HZ * 5;
+ s_info->tokens_max = HZ * 10;
+ s_info->tokens_jfy = jiffies;
+ s_info->tokens_lock = SPIN_LOCK_UNLOCKED;
%age of CPU given = fr/div. 1 token gets added per 4 jiffies.
Ideally these numbers should be as low as possible, 20 tokens per 100
jiffies may result in midly erratic behaviour.
`tokens' sets the bucket fullness of newly created s_context's.
`tokens_max' sets the limit that an idle s_context's bucket may fill
to.
> o Are hard CPU time limits possible?
> (lets say Virtual N becomes at most 20% of the total
> available CPU time, or Virtual M has to get at least
> 10% ...)
TBF isn't a `hard' algorithm. Mind you, the O(1) scheduler isn't a
`hard' scheduler :-). You could force a task switch if a context has
no tokens left whatsoever, but in quite simple to reproduce
circumstances you could be left switching tasks every jiffie, which
blows your CPU cache. However, with an `nproc' ulimit, the system
would still be very usable if a particular s_context started a fork
bomb, as they would all get scheduled to the lowest possible priority,
and your `root' server interactive tasks would be getting real-time
priority (comparitively).
You would need to implement a CBQ for `hard' CPU time limits. CBQ is
Class-Based Queueing. In this instance, your scheduling "classes" are
s_context structures.
The main scheduler would spot if a scheduled task has a s_context with
the sched bit set, and if so then it would use the *per-s_context
runqueue* structure to schedule time within processes in that
s_context. You would need to understand that scheduler really well to
do this.
> currently its 2.4.20/21 based, but the scheduler change
> is minimal, and I guess I will do it for 2.5.x anyway ...
> so that shouldn't be the problem ...
Yes, 2.5 has the O(1) scheduler by default IIRC.
-- Sam Vilain, sam_at_vilain.netYour freedom to swing your arm ends where my nose begins. - anon.