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

RE: [Xen-users] Xen 3.0 and resources guarantees - CPU, RAM...

To: "Jordi Segues" <jordisd@xxxxxxxxx>
Subject: RE: [Xen-users] Xen 3.0 and resources guarantees - CPU, RAM...
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Mon, 22 Jan 2007 17:40:25 +0100
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 22 Jan 2007 08:43:28 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <9e04a9140701220805n8e7ff0ak5ab48ebca2dd3155@xxxxxxxxxxxxxx>
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: Acc+P1IMa3jbhvHgSxS6T3C3g4FBMQAAer1Q
Thread-topic: [Xen-users] Xen 3.0 and resources guarantees - CPU, RAM...
 

> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Jordi Segues
> Sent: 22 January 2007 16:06
> To: Petersson, Mats
> Cc: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] Xen 3.0 and resources guarantees - 
> CPU, RAM...
> 
> First of all, thanks for your answer Mats.
> 
> 
> > RAM is definitely "not a problem", as RAM is "hard limits" 
> to each guest (and you can either let Dom0 dole it out to 
> other guests, or, my preferred option, by giving Dom0 a hard limit).
> 
> Ok for the RAM
> 
> > > I'm a little confused.
> > > How vcpu and cputime work?
> > Not entirely sure what you're asking (not that I'm sure 
> I'll be able to answer either, as I'm not that sure about how 
> the scheduler and such works).
> 
> I mean, what's the function of a vcpu?

It's a virtual CPU, which means that it's the software represenation of one 
physical CPU for one virtual machine at the present time.
> If I have a dual-core processor, do I have to set vcpu to 2?

No, you can set it to 1, 2, 3, 4, 7, 46 or any other number you like. 
(Obviously, if you're a "anti-Valentino Rossi", you'd NOT select 46 [sorry, 
personal joke - may not get to most of the audience - ignore if you don't 
understand], nor does it really make sense to set it much higher than around 2x 
the number of actual cpu-cores in the system, unless you have many domains with 
very ligth loads - you want to aim for about 60-95% CPU utilization in your 
system. Going to 100% will mean that you may find yourself in trouble with any 
task that requires some real-time behaviour). 

> Or vcpu is independent of the number of real cpus? (cause 
> they are virtual)
Yes, they are independent (as described above). 

> Could I define 4 vcpus for a dual-core processor?
Yes.

> And where do you associate a vcpu to a core or cpu?

In the configuration file for the virtual machine, but it can also be done 
after-the-start with xm vcpu-set and xm vcpu-pin. 
> 
> So I understand that you can associate a DomU to one or more vcpus,
> and more it has, more it will have cpu time?
> 
> 
> To give the priority to a guest I must do it giving it more vcpus?

Not necessarily, in fact it's probably not so good to do that. There are 
scheduler parameters that you can play with too, and those are better at 
regulating which guest gets how much CPU-time. The command "xm sched-credit" 
will allow you to change the scheduler parameters, and they are "cap" and 
"weight". Although I've never played with those, so I can't say exactly what 
you should change to achieve something in particular.

> 
> > > Are this parameters mandatorys? I mean can you reserve a CPU
> > > percentage or time to a guest even if it doesn't use it?
> > Why would you want to reserve time for a guest that then 
> doesn't use it? That's not meaningfull, the whole point of 
> virtualization is to improve the utilization of machines... 
> So if the CPU is stting idle for guest 3, why not run guest 2 
> that is needing CPU time.
> 
> Ok, you're right.
> So if a guest uses 100% of the cpu, and another guest wants cpu too,
> then each guest will have 50% right?

On average, yes. Because of the time quantification, if you look at it on a 
very short-term basis, one may get more usage than the other, but over a 
slightly longer period, they should even out (assuming scheduling parameters 
are equal!). 


> 
> And what if I want one guest to have 2/3 of the cpu and the other 1/3?
> 
> Can you give a guest various vcpus?

The number of vcpus for a guest is like the number of physical CPU's in a real 
machine, it determines the maximum number of threads that can run 
simultaneously. But because of virtualization, the actual physical CPU's can be 
more or less than the number of VCPU's, so the threads may of course not 
actually run simultaneously, if you see what I mean. Put another way, one VCPU 
is what the guest sees as a physical CPU, but several VCPU's can (and will) 
share the same machine-cpu. 

> 
> >
> > SEDF (which I believe stands for Schedule Earliest Deadline 
> First), used to be the default, but now it's using a "Credit 
> Scheduler", which allows "work conservation", which means 
> that an idle CPU can be used to "migrate" a VCPU from one CPU 
> to another in the same system, which means that the idle time 
> is reduced if two competing runnable VMs happen to be on the same CPU.
> >
> This is interesting, it means you don't associate a vcpu to a 
> real core/cpu?

They are not STRICTLY associated. You can set which physical CPU's your virtual 
machine runs on, but each VCPU isn't (normally) tied directly to a particular 
physical CPU. Some examples:

A system with one cpu, let xen decide which one. 
vcpus=1
cpus=""   

A system with two cpus, we decide which CPU's to use:
vcpus=2
cpus="2,3"  #Only run on cpu socket 2, both cores of dual core CPU. 

A system with 5 cpus, we don't want to run on the first two cores (for example, 
allow Dom0 to run on 0-1), but let Xen distritute otherwise:
vcpus=5
cpus="^0-1"

--
Mats


> 
> 
> 
> I don't really find clear documentation about all this.
> Sorry for that question storm ;)
> 
> You help is appreciated.
> 
> 
> 
> -- 
> Jordi Segués Daina
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
> 
> 
> 



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