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

[Xen-users] Xen Scheduler: Credit Scheduler ?

To: <xen-users@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-users] Xen Scheduler: Credit Scheduler ?
From: "Ott, Donna E" <donna.ott@xxxxxx>
Date: Sat, 18 Nov 2006 13:42:15 -0500
Cc: Emmanuel Ackaouy <ack@xxxxxxxxxxxxx>
Delivery-date: Mon, 20 Nov 2006 05:11:44 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AccLQ6q8cWNjOnv+TS+C66XYQ+lAug==
Thread-topic: Xen Scheduler: Credit Scheduler ?
 Following up on the strange behavior I've seen, here is a summary and
then my most
Recent experiment. 
I've been having a discussion with Emmanuel and he has urged me to post
to the list.
Up to now we have talked about what could be going wrong and whether
there was blocking or not, etc. 
 Basically, when I run 2-4 2vcpu domUs one of them gets "stalled" at
 .5-.6 CPU % after a little while. At first, they all
 balance nicely (as shown by xm top),then something shifts. I have even
had TWO domUs get "stalled" to .5-.6- while the third or fourth happily
run on dividing up the left over cpu.
When I set xm sched-credit -C 30 -
 which means I limit each domain to 30% of a CPU- the lock-out
phenomena STILL occurs! So even though all(three) of the domUs can
easily "fit" (I have a 2 way ia64 box) they are still somehow getting
disorganized.  (note I can easily run the benchmark like this
by itself on one domU or on dom0 )

Yesterday I was able to do some more experiments and using vcpu-pin and
xm sched-cred
I was able to xm sched-credit -C  cap each domU to only 30% of a real
processor (thus two vcpus consigned to only 30% of a real processor) and
then I used vcpu-pin to pin each vcpu to a real processor. I did this
with 3 domUs for my experiment. I pinned each vcpu to a different
"real-cpu." When I ran this configuration I STILL got a "stalled"
domU. Looking at vcpu-list I found that the "stalled" domU had been
blocked in a few 
Samples but not all- but a strange thing that I saw was that even after
it had been "unblocked" from being blocked- the time on the processor
was not updated. SO, a vcpu appeared to be blocked but then was
unblocked for a significant amount of time, yet did not appear to get
any more "time."  I am working on some other things to figure this out. 
  Sometimes it runs beautifully other times we get a "stall" (note that
a "stall" is not the death of the domU it's a situation where that domU
is getting like .5/.6 cpu % and the running software on it is
"zombie-fied"
Once you ctl-c on that domU *after the others are done* you can "wake"
it up and it runs.

Any input/ideas? What could be happening?



Thanks!


Here's my configuration:
4 way capable 2way ia64 Madison 1.2GHz processor server running RHEL-4AS
Xen-unstable snapshot from Oct 29 24GB of memory, each guest has 2GB of
memory assigned Each guest has its own fiber channel 140GB standalone
disk

As far as my application- its SDET an ancient and SPEC system benchmark.

Thanks!
Donna "searching" Ott


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

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