Re: [Xen-users] CPU assignment and sched-credit

[Dario Faggioli <raistlin.df@xxxxxxxxx>]

On mer, 2014-06-11 at 08:35 +0200, lee wrote:
> Hi,
> 
> looking at [1], I start to think that it would make a lot of sense to
> overcommit CPUs on a server with very light load and let the scheduler
> handle the assignment by time slices as demand requires.  I've been
> reading that overcommitting CPUs is a bad idea, yet I don't understand
> what the point is in letting N-1 CPUs idle while one of the N CPUs is
> busy and the VM driven by it could benefit from being able to use more
> CPUs.
> 
Well, what makes and not makes sense, depends a lot, of course, on your
workload, purposes, etc. Certainly, if you're looking at virtualization
for consolidation, then you probably want a few 'theoretical
overcommit', i.e., you probably want to have the total number of vCPUs
of all the VMs to be greater than the total number of pCPUs (which is
overcommitting), knowing that it will be very unlikely that all those
vCPUs will be active at the same time (that's why I'm calling it
'theoretical').

For sure, handling the overcommitted situations in the best possible way
(again, best in terms of what the sysadmin wants and configures, in this
case through weights, etc) is the job of the scheduler. If you always
have less vCPUs than pCPUs then you don't need a scheduler (well, that's
an over-simplification, but at least, if you don't have contention,
you're not stress the scheduling algorithm, let's say).

> IIUC, the scheduler will preempt a VM after so much time anyway and
> allow other VMs to run.  When CPUs are not overcommitted, it wouldn't
> need to preempt anything because all VMs can run simultaneously.  (I
> don't know if does preempt a VM anyway.)
> 
Indeed. Yes contention ==> scheduler do its job. No contention ==>
scheduler does next to nothing.

As per whether there might be interruptions and context switches, well,
yes, such things are not completely ruled out, but you'll see very few
of them, and for different reasons than the characteristics of the
scheduling algorithm.

> With CPUs overcommitted and all VMs busy, overall throughput can (will)
> be diminished, and latency could become an issue.
> 
Indeed, and true for scheduling in general, as you study it in CS
courses. :-)

> With very little load, it seems to make sense to just let all VMs have
> all CPUs.  There's probably a point at which it would be better to do
> some fine tuning, based on the actual loads, and before that point is
> reached, what could be better than letting all CPUs to all VMs?
> 
This part, I'm not sure I understand.

> Am I wrong or missing something?
>
Apart from the last paragraph (where I'm not sure what you mean), no.

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users