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

From: Sam Vilain (sam_at_vilain.net)
Date: Tue 11 Nov 2003 - 15:43:08 GMT


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, 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


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 Tue 11 Nov 2003 - 15:44:40 GMT by hypermail 2.1.3