From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Tue 11 Nov 2003 - 16:28:42 GMT
On Tue, Nov 11, 2003 at 03:43:08PM +0000, Sam Vilain wrote:
> 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...
hmm, maybe Rik knows more on that issue?
> 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.
would a /proc/virt/<ctx>/sched ease that hassle, or
is this just insufficient?
thanks,
Herbert
> Other things I originally intended, eg CBQ for vservers are probably
> made unnecessary by CKRM.
> --
> Sam Vilain, sam_at_vilain.net
>
> "Revolution is the opiate of the intellectuals"
> - "Oh, Lucky Man" -
>
>
> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver