RE: [Xen-devel] "cpus" config parameter broken?

["Ian Pratt" <Ian.Pratt@xxxxxxxxxxxxx>]

> 1) Is the "cpus" parameter expected to work in a config file or is it
> somehow deprecated?
>    (I see there is an "xm vcpu-pin" command so perhaps this is the
> accepted way to
>    pin cpu's?)

It's expected to work.

> 2) Pinning via the "cpus" parameter calls vcpu_set_affinity() but I've
> always thought the term
>     "affinity" expresses a preference not a restriction.  If the call
> to setaffinity did get
>    made properly, would the scheduler really restrict the vcpu to
> certain pcpu's?  And
>    what happens if the vcpu is ready to schedule but none of the
> restricted set of pcpu's is available?

It's a restriction. Each of the values in the mask is processed modulo the 
number of physical CPUs.

> 3) Does "cpus" really have any real-world usage anyhow?  E.g. are most
> uses probably just
>     user misunderstanding where "vcpu_avail" should be used instead?

I'm sure some admins use it to good effect in hand placing domains on CPUs, 
especially in a NUMA context. In most cases its typically best to be fully work 
conserving and give Xen's scheduler full flexibility.

There was an extension to the cpus= syntax proposed at one point that I'm not 
sure whether it ever got checked in. The idea was to allow the cpus= parameter 
to be a list of strings, enabling a different mask to specified for each VCPU. 
This would enable an admin to pin individual VCPUs to CPUs rather than just at 
a domain level.

I'm not a huge fan of the cpus= mechanism. It would likely be more user 
friendly to allow physical CPUs to be put into groups then allow domains to be 
assigned to CPU groups. It would also be better if you could specify physical 
CPUs by a node.socket.core.thread hierarchy rather than the enumerated CPU 
number.

Ian







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