Re: [uml-user] UML Scheduler Command Line Option?

[Nick Craig-W. <nc...@ax...>]

On Tue, Jan 28, 2003 at 07:50:49PM -0500, James Neal wrote:
> On Tue, 2003-01-28 at 19:16, Ben Russo wrote:
> > Is there any way to GUARANTEE that a UML will not be able to use
> > more than a certain amount of CPU on the HOST?  I mean if the UML
> > Kernel had a scheduler patch to guarantee a certain amount of
> > idleness?  The UML Kernel could have a command line switch that
> > said pct_idle=XX
> > 
> > Then the UML kernel would always be idle XX out of 100 UML-Kernel
> > process time slices?  I could then set a UML pct_idle at 50, and
> > guarantee that it would run precisely half as fast as normal, and
> > would never use more than 50% of the HOST systems CPU.
> 
> That _would_ be nice.
> 
> The closest thing I've found to that was a rather old sourceforge
> project (http://fairsched.sourceforge.net/).
> 
> I eventually loaded in Rik van Riel's "fairsched" patch
> (http://surriel.com/patches/), and it's doing a good job on my UML
> farm.  It doesn't give you fine grained control, but it does make
> sure that all the users on the system get equal access to the
> processors.  This works out well for me, since each of my UMLs has
> its own user.

I found in my tests that fairsched works extremely well.  It is
absolutely necessary when using uml in tt mode if you want to avoid
one uml taking over all the CPU.  My standard test involved running
lots of CPU intensive processes in some umls and fork bombs in
another.

However with skas mode because there is only one process running at
any time and at most 4 processes the above rather violent test works
perfectly without fairsched.  Ie no matter how hard you try, a skas
UML can never get the load it contributes to the system above 1.0
(which is exactly what fairsched does on a per user basis).

However you can start each UML off with a different nice value which
means that you can (roughly) allocate percentages of CPU to each UML.
This allocation is worst case allocation assuming each UML is running
continuously wanting more CPU than it actually can get.  This is not
quite what the OP wanted but very useful if you want to control how
UMLs share.

I think (but I haven't tested) that fairsched interferes with nice
levels though.

Here is a small bit of analysis I did on what nice levels actually do
(measured in debian 2.4.20 kernel which contains the standard
scheduler).

First define realnice

  realnice = int((24 - nice)/4)

Ie

nice realnice
 19  1
 18  1
 17  1
 16  2
 15  2
 14  2
 13  2
 12  3
 11  3
 10  3
  9  3
  8  4
  7  4
  6  4
  5  4
  4  5
  3  5
  2  5
  1  5
  0  6
 -1  6
 -2  6
 -3  6
 -4  7
 -5  7
 -6  7
 -7  7
 -8  8
 -9  8
-10  8
-11  8
-12  9
-13  9
-14  9
-15  9
-16 10
-17 10
-18 10
-19 10

Processes are scheduled weighted according to realnice.  (I tested
this empirically and it worked so exactly that I didn't bother to
examine the scheduler code to see if was right ;-)

Imagine we have n processes running, n-1 with a base realnice of B and
one with a realnice of P, then the process with realnice P will get
this much CPU

  P / ((n-1)*B + P)

And a base process will get this much

  B / ((n-1)*B + P)

So ratio of our process / base process is

  P / B

So raising and lowering the nice levels will do exactly what we want
ie raise and lower the relative CPU ratios between our process and the
base process.

Ie if base is B=4 (nice 7) then realnice P=8 (nice -10) will double
the CPU usage and realnice 2 (nice 14) will halve it relative to the
base processes.

So that gives the overall idea.  Now for the most general case :-

Assuming we are running n processes each with a realnice of P(n) then
process i will receive this much of the CPU

  P(i) / ( P(0) + P(1) + .. + P(n-1) )

which is equal to

  P(i) / (n * average(P))

This gives a way of working out exactly what the share of CPU each
process could get if it was working flat out.

If you want to use this in practice you'll want to pick a base
realnice level for your UML processes and then you can give UMLs CPU
boosts or cuts above or below the base level as per the example above.
The levels are fairly coarse and not very extreme but useful
none-the-less.

I hope that is comprehensible and not too much maths!

-- 
Nick Craig-Wood
nc...@ax...