* Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx> [2005-11-16 16:07]:
> > The 'cpu' option in domain config files will pin VCPU0 of a domain.
> > This is not as useful now that domains can have more than 1
> > vcpu. This patch changes 'cpu' to 'cpus' and takes a list of
> > physical cpus the domains' vcpus can use and will pin the
> > vcpus upon domain creation.
> >
> > cpus = [1] # this starts all domain vcpus pinned to CPU1
>
> I think this patch is generally a good thing. Should we support cpu= as
> backward compatible legacy option?
I pondered that as well. No reason we can't. Some documentation should
avoid any confusion. I'll rework the patch to support cpu=X and
cpus=[].
>
> > The list is circular, so in a domain with the following config:
> >
> > vcpus = 4
> > cpus = [0,3,7] # Use any of 0, 3, 7 for this domain.
> >
> > would see vcpus 0-3 pinned to cpus 0,3,7,0 respectively.
>
> Actually, although this is a reasonable syntax, I think we'll probably
> interpret it differently in future when we have CPU load ballancing: I
> think we'll want to list the set of CPUs that a given _domain_ can use
> rather than pining individual CPUs.
I think the list is already representative of that idea: this is a list
of cpus that any of the vcpus in this domain can use. Currently without
a load balancer we only get one go at vcpu to cpu allocation.
Also, no reason we can't replace the current algorithm down the road
with a call out to the load balancer which would supply the mappings.
> However, I wander whether this should be a string so that we can list
> e.g. cpus='0-3,5,^1'
I like that notation better, but it opens up a few questions. Do you
mean the commas to indicate which cpus each vcpu is allowed to use, or
just a list of cpus the domain can use? Also, I take ^1 to mean any
cpu, yes?
I'll end up converting the string into a big list of possible cpus to
use and for each vcpu pick a cpu and pin it there.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh@xxxxxxxxxx
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|