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] [PATCH][RFC] consider vcpu-pin weight onCreditScheduler

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][RFC] consider vcpu-pin weight onCreditScheduler TAKE2
From: Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>
Date: Thu, 28 Jun 2007 18:23:36 +0900
Cc: Emmanuel Ackaouy <ackaouy@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 28 Jun 2007 02:22:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2A81716.1166C%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C2A81716.1166C%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi, Keir and Emmanuel

 Thank you for your discussions.
It is very meaningful for me.
I try it again for simplify the code.

Anyway the reason of this kind of complex is come from.

Following 5 conditions should consider for this issue(vcpu-pin-weight).

1)Domain    1-n
2)vcpu      1-n
3)vcpu-pin  1-n
4)Each domain has weight, but it should be treated as vcpu-weight.
since each vcpu pin-map is not same for each domain.
5)Each vcpu has credit, but it is changed each time slice.
(Sometimes accounted, and othertimes are not.)


Thanks
Atsushi SAKAI



Keir Fraser <keir@xxxxxxxxxxxxx> wrote:

> 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