atropos scheduler broken

[Diwaker Gupta <diwakergupta@gmail.com>]

Hi everyone,

I've been playing around with the atropos scheduler last couple of
days, and I'm quite convinced that it *does not* enforce the soft real
time guarantees. Maybe I'm using the wrong parameters or something, so
let me describe my experiment:

o first I create 2 VMs -- VM1 and VM2
o then I change their atropos params as follows:
$ xm atropos 1 10 100 1 1
$ xm atropos 2 70 100 1 1
Ideally, this should guarantee that VM1 gets 10ns of CPU time every
100ns, and VM2 gets 70ns every 100ns, and that any left over CPU time
will be shared between the 2.

o after this I write a simple program that computes fibonacci numbers
using naive recursion to eat away all the CPU, and loops around
indefinitely. Programs in both VMs are identical, and I start them
within seconds of each other.

o I take reading from xm list a few seconds after the programs start,
as my base reference:
                                                      CPU-TIME
VM1                1       63    0  -----    173.5    9601
VM2                2       63    0  -----     10.9    9602

o Thereafter I take readings every few seconds. The abosolute values
of CPU time are not that important, if the *rate* at which CPU time
increases in both the VMs can reflect the atropos scheduling, that is
just as well.

Here are some of the subsequent readings:
VM1                1       63    0  -----    178.0    9601
VM2                2       63    0  -----     15.4    9602

VM1                1       63    0  -----    216.9    9601
VM2                2       63    0  -----     54.1    9602

VM1                1       63    0  -----    308.4    9601
VM2                2       63    0  -----    145.3    9602

VM1                1       63    0  -----    428.4    9601
VM2                2       63    0  -----    265.1    9602

As can be seen, the CPU times of both VMs are increasing at almost
*identical* rates. If the atropos params were working, VM2's cpu time
should have been increasing a lot faster.

Has anyone had this problem before? I'll start looking at the code,
but since I'm not familiar with Xen's scheduling code, it might be a
while. In the meanwhile if anyone has any pointers, it will be great.

TIA
-- 
Diwaker Gupta
http://resolute.ucsd.edu/diwaker


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl