[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH][RFC] consider vcpu-pin weight on CreditScheduler TAKE2


  • To: Emmanuel Ackaouy <ackaouy@xxxxxxxxx>, Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Wed, 27 Jun 2007 13:31:02 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 27 Jun 2007 05:29:04 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Ace4twXZRJb1jCSqEdyz1QAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH][RFC] consider vcpu-pin weight on CreditScheduler TAKE2

On 27/6/07 13:21, "Emmanuel Ackaouy" <ackaouy@xxxxxxxxx> wrote:

>> Which is the best way to solve?
> 
> If you could solve the generic problem in a simpler way, I would
> not be opposed to it. But +365 lines in what is already a fairly
> complex accounting code path doesn't seem right to me.
> 
> I can't even understand what weights mean when every CPU
> has a different pin cpumask. Weights only make sense to me
> when VMs compete for resources.
> 
> In my opinion, adding the concept of dynamic partitioning (or
> segmentation) of the host system would allow a bunch of people
> to no longer have to pin their VCPUs. This is desirable.

Partitioning is a very sensible simplification in many (most?) cases, but
would need plumbing all the way up through xen-api, which is a pain. I still
suspect that the patch could be simplified even without interface changes. I
don't understand the need to add extra complexity on every accounting
period.

 -- Keir


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.