Re: [PATCH] xen, tools/python/xen: pincpu support, vcpus, add vcpu to cpu map

[Sam Gill <samg@seven4sky.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3880 bytes --]

Message: 6
Date: Thu, 14 Apr 2005 11:24:07 -0500
From: Ryan Harper <ryanh@us.ibm.com>
Subject: Re: [Xen-devel] [PATCH] xen, tools/python/xen: pincpu support
	vcpus,	add vcpu to cpu map
To: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
Cc: Ryan Harper <ryanh@us.ibm.com>, xen-devel@lists.xensource.com
Message-ID: <20050414162407.GG27571@us.ibm.com>
Content-Type: text/plain; charset=us-ascii

* Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> [2005-04-14 10:50]:

>>> > The following patch updates the dom0 pincpu operation to read 
>>> > the VCPU value from the xend interface rather than 
>>> > hard-coding the exec_domain to 0.  This prevented pinning 
>>> > VCPUS other than 0 to a particular cpu.  I added the number 
>>> > of VCPUS to the main xm list output and also included a new 
>>> > sub-option to xm list to display the VCPU to CPU mapping.  
>>> > While working on the pincpu code, I fixed an out-of-bounds 
>>> > indexing for the pincpu operation that wasn't previously 
>>> > exposed since the vcpu/exec_domain value was hard-coded to 0.
>>    
>>
>> 
>> Ryan, good progress, but I'd like to propose a couple of extentions:
>> 
>> It would be useful if you could update it so that pincpu enabled you to
>> specify a set of physical CPUs for each VCPU e.g.
>> 
>> "xm pincpu mydom 1 2,4-6" which would allow VCPU 1 of mydom to run on
>> CPUs 2,4 and 5 but no others. -1 would still mean "run anywhere". Having
>> this functionality is really important before we can implement any kind
>> of CPU load ballancer.
>  
>

> Interesting idea.  I don't see anything in the schedulers that would
> take advantage of that sort of definition.  AFAIK, exec_domains are
> never migrated unless told to do so via pincpu.  Does the new scheduler
> do this?  Or is this more of setting up the rules that the load balancer
> would query to find out where it can migrate vcpus?


>> Secondly, I think it would be really good if we could have some
>> hierarchy in CPU names. Imagine a 4 socket system with dual core hyper
>> threaded CPUs. It would be nice to be able to specify the 3rd socket,
>> 1st core, 2nd hyperthread as CPU "2.0.1".
>> 
>> Where we're on a system without one of the levels of hierarchy, we just
>> miss it off. E.g. a current SMP Xeon box would be "x.y". This would be
>> much less confusing than the current scalar representation.
>  
>
 > I like the idea of being able to specify "where" the vcpu runs more
 > explicitly than 'cpu 0', which does not give any indication of physical
 > cpu characteristics. We would probably need to still provide a simple
 > mapping, but allow the pincpu interface to support a more specific
 > target as well as the more generic.

> 2-way hyperthreaded box:
> CPU     SOCKET.CORE.THREAD
> 0       0.0.0
> 1       0.0.1
> 2       1.0.0
> 3       1.0.1


Just my opinion, but for end users, and people who are going to have to 
configure this
whole system, it would be a far greater impact to just develop a simple 
tool that just shows
you how many cpus you have to work with. (also a debugging tool, to see 
if your cpus are registering)

such as "xm pincpu-show" and "xm pincpu-show-details" for a more verbose 
listing

and once you developed the function that could return those values, you 
could use that function
to map different domains to different cpus, or different cpus to 
different domains.

Then the next step would be creating some helper functions "xm 
pincpu-add" so you could add a cpu to
a domain, or "xm pincpu-move" to move a cpu from one domain to another. 
In addition you could have
"xm pincpu-lock"/"xm pincpu-unlock" which would only allow one single 
domain to access that cpu.

I am just thinking that maybe if you detail (if you have already not 
done so) what you want the end result to
be, than it might be easier to figure out how to implement the lower 
level functions more efficiently.

Thanks,
 Sam Gill



[-- Attachment #1.2: Type: text/html, Size: 6112 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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