WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] atropos still broken?

To: xen-devel@xxxxxxxxxxxxxxxxxxxxx, Diwaker Gupta <diwakergupta@xxxxxxxxx>
Subject: Re: [Xen-devel] atropos still broken?
From: Gregor Milos <gm281@xxxxxxxxxxxxxxxx>
Date: Thu, 27 Jan 2005 22:11:31 +0000
Delivery-date: Fri, 28 Jan 2005 03:40:49 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <1b0b4557050126202540ed6469@xxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <1b0b4557050126202540ed6469@xxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.7.1
> Hi everyone,
>
> This is for Xen 2.0.3. I'm really interested in the functionality of
> atropos (enforcing CPU partitioning in a non work-conserving fashion).
> As I had reported earlier, atropos seemed broken in 2.0. It still
> seems broken now:
>
> $ xm list
> Name              Id  Mem(MB)  CPU  State  Time(s)  Console
> Domain-0           0      123    0  r----     49.1
> vm1                1       47    0  -b---     29.7    9601
>
> $ xm atropos 0 10000 100000 50000 1
> $ xm atropos 0 70000 100000 50000 1
>
> Now if I run the slurp program (posted earlier in this list) in vm1,
> it eats up all the CPU. If I start the same program in dom0 as well,
> both get ~50% of the CPU. With those parameters, ideally vm1 should be
> getting 70% and no more, and dom0 should be getting 10% and no more.

I do not remember exactly what order are the 5 parameters in, so I am not 
quite certain what you are trying to set. Anyhow the Atropos is a kind of 
earliest deadline first scheduler that tries to fullfill the guarantees 
first, but if there is any spare CPU time left it will do best effort 
scheduling (that is the reason dom0 is getting 100% CPU when you run slurp in 
it).

> So it seems atropos is still broken. Is a fix being worked upon? I'd

I do not think anybody is working on it at the moment (Mark, as I recall you 
were the last one to play with Atropos, can you possibly give more details?), 
but since I am familiar with the scheduling code (although I have never 
worked on Atropos really), I am keen on tackling this problem.

> really like to help in any way I can. I'm familiar with the Xen
> scheduling code; if any of the developers have any idea of where/what
> the bug is, I'd like to take a crack at it.

That's great, we can try to fix it together than (I contact you offlist 
tomorrow).

Cheers
Gregor

-- 
Quidquid latine dictum sit, altum viditur --- Anon


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

<Prev in Thread] Current Thread [Next in Thread>