About this list Date view Thread view Subject view Author view Attachment view

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


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:


> 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

> 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.net

Your freedom to swing your arm ends where my nose begins. - anon.

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Thu 12 Jun 2003 - 13:27:37 BST by hypermail 2.1.3