From: Sam Vilain (sam_at_vilain.net)
Date: Wed 26 Feb 2003 - 21:39:37 GMT
On Wed, 26 Feb 2003 04:59, you wrote:
> Would it be possible for you to provide a complete set of diffs from
> 2.4.21-pre4-ac6 to ...+ctx16+your_patch? I think my runs of patch may
> be failing in different ways that yours. That could explain the
> differences I am seeing. I am using patch version patch-2.5.4-r4 under
> Gentoo Linux (sys-devel/patch-2.5.4-r4 in emerge-ese).
Alright. I should have made them against the aftermath of `patch -F 0'
(turn off fuzz - which I'll be doing from now on as a rule...)
I've put them at a temporary URL:
http://www.soreal.co.uk/~sv/patch-2.4.20-ac2-ctx16
http://www.soreal.co.uk/~sv/patch-2.4.21-pre4-ac6-ctx16
Note: currently this patch doesn't do a good job of scheduling in the
extreme case (ie, if one context starts 50 CPU hogs, it still gets most of
the CPU); there's only so far I can penalise processes, or give boosts to
others. At least the contexts exceeding their quota will be the
equivalent of about nice +15 :-).
An alternative that would provide harder scheduling would be to give each
security context with --flag sched its own run queue, and make it look
like a single process to the main scheduling code. ie CBQ scheduling.
This TBF scheduling could optionally be applied at the next level, eg a
token bucket in user_struct for fair scheduling.
Remember to tune the values in kernel/sys.c for your needs.
/* 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;
The `fill rate', set to one above, divided by the `divisor', is the ratio
of CPU that processes in each context will get. So, eg if you have 16
contexts you want to equally schedule, you would set the divisor to 16 and
leave the fill rate at 1. If you had a 4-way SMP system, you effectively
have more 4 times more tokens to distribute per second so you would set
the fill rate to 4 (or divide the divisor by 4).
tokens_max sets the size of the bucket; reduce to make the code take
scheduling action more quickly.
-- Sam Vilain, sam_at_vilain.netReal Programmers never "write" memos. They "send" memos via the network.