* Ewan Mellor <ewan@xxxxxxxxxxxxx> [2005-11-09 08:23]:
> On Tue, Nov 08, 2005 at 05:21:32PM -0600, Ryan Harper wrote:
>
> > Resending, rediffed against changeset: 7701:abbe3df33774
>
> Thanks for your resends, Ryan. Your two patches are in my tree at the moment,
> and I'm testing them.
Great!
>
> There are now so many fields with "cpu" in the name that I was looking over it
> wondering if there were a few we could lose now. Perhaps we could review them
> on the list.
Yeah, as I was wading through this I was thinking the same thing.
>
> I count
>
> vcpus the number of virtual CPUs this domain is configured to use.
> vcpu_avail VCPU availability bitmap
> vcpu_count same as vcpus, just in the getVCPUInfo sxpr
> cpumap VCPU-to-CPU bitmap list
> cpu configuration pinning VCPU 0 to the specified physical CPU
> max_vcpu_id
> online_vcpus
>
> as well as the obvious
>
> cpu_time
> cpu_weight
>
> So could you explain the semantics of max_vcpu_id and online_vcpus, compared
> with vcpus and vcpu_avail in particular? I'm afraid I've lost track.
'max_vcpu_id' is the highest id of a vcpu that has been
created/initialized. So, for instance, after booting dom0 SMP on a 4
way, the hypervisor's domain builder creates one VCPU for each physical
cpu leaving max_vcpu_id=3.
'online_vcpus' is a count of the number of vcpus that can be scheduled in
a domain (they are runnable, that is VCPUF_down is not set, which
happens when we disable/unplug vcpus).
'vcpus' is the value parsed from a domain's config file, ie, the number of
vcpus you want your domain to have.
'vcpu_avail' is a bitmap (probably should convert it to a list since we
have been tossing the C-ism out) indicating which vcpus are available
(runnable, enabled, etc.). Currently, vcpu_avail is derived from
'vcpus', (vcpu_avail = (1 << vcpus) - 1) and assumes that all possible
vcpus are available.
In some cases, we don't have a configuration file which would have the
'vcpus' element (dom0 is one such example). Such domains are usually
running prior to starting xend in which case the info dict
returned from xc_domain_getinfo contains the run-time variables
'online_vcpus' and 'max_vcpu_id'. We can use those values to calculate
vcpu_avail.
Actually, rather that using max_vcpu_id+1 to calculate vcpu_avail for
running domains as I did in my patch we should build it with a loop
check each vcpu if it is up or not:
for v in range(0,info['max_vcpu_id']+1):
vinfo = xc.vcpu_getinfo(domid,v)
if vinfo['online']:
vcpu_avail |= 1 << v
One of the difficulties we have is that is is not always clear in the
code where we want configuration information (ie, how many vcpus did you
want your domain to have) or runtime info (which vcpus in this domain
are online right now). I think vcpu_count is just one of those cases,
one could want access to either type but we only have one method
and if you are not aware of what that means, then we are possibly
introducing bugs.
Personally I'd like to see a separate dict for config and runtime info
config = parseConfig(c) # only filled with values from config file
info = dom_get(domid) # current runtime info as returned from HV
Possibly too late in the game for this sort of rework.
--
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
|
Home