On Tue, 11 Nov 2003 06:56, Herbert Poetzl wrote;
> I would like to add a 'generic' interface
> to the next development release, which works
> for O(1) as well as for non O(1), although
> slightly different ... you've already implemented
> a tuning syscall for your scheduler stuff, could
> you make a first proposal how this syscall would
> look like, and what you would like to 'adjust'
> in future versions?
I can knock up what I think would be good; but ideally it should be
modeled as closely as possible after the CKRM syscalls. Right now I
don't have the time to do that research unfortunately...
Here's the details of the syscall currently;
struct vcmd_set_sched_v1 {
uint32_t ctxnum;
/* this is the context number to operate on, which currently must be
the same as the current context */
uint32_t options;
/* Options - this is a bitwise field performing admin stuff.
#define TBF_SCHED_ENABLE 0x0001
#define TBF_SCHED_DISABLE 0x0002
This should be adequate for denoting other types of scheduling,
should the whole integration with CKRM thing not work out. */
/* The rest of the fields are specific to the fact that it is a TBF
algorithm being used. Note that the algorithm could apply
equally well to a non-O(1) scheduler, but honestly - what's the
point of inplementing that ? :-) This data area should probably
be a (possibly variable length) `union' of the tunables for all
the available types of scheduling. */
int fill_rate;
int period;
int fill_level;
int bucket_size;
};
Other things that I might like to add later;
a) `hard luck' scheduling - a per-vserver flag that only allocates
a maximum number of jiffies to a context as they have tokens
left, and when they are `empty', immediately stop the process
and put them on the end of the inactive runqueue. This would
effectively stop a vserver from getting allocated cycles if they
have no tokens, but if everything is `running on empty' they
will still get 1 jiffie slices allocated.
b) `hard' scheduling - a per-vserver flag that _prevents_ the
vserver from getting allocated cycles if they have no tokens.
ie, no tokens = less priority than the idle process.
c) some mechanism for reading the current values for a particular
context, without all that hassle of parsing /proc/X/status, so
that a manager process could watch what was going on and take
action, record total tokens used (or read the total kept
internally), etc.
Other things I originally intended, eg CBQ for vservers are probably
made unnecessary by CKRM.
--
Sam Vilain, [EMAIL PROTECTED]
"Revolution is the opiate of the intellectuals"
- "Oh, Lucky Man" -
_______________________________________________
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
