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

[Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>]

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