Re: [Xen-devel] RE: [Xen-users] Xen 3.0 Dom0 Smp enable?

[Stephan Diestelhorst <sd386@xxxxxxxxxxxx>]

>>Certainly it will be easier to do so in xend, but I'm more

>>concerned with the hypervisor being responsible responsible 
>>for choosing the vcpu to cpu mapping.  I'd like to see dom 
>>creation support the passing of a cpumap and have the 
>>hypervisor cycle through the physical cpus marked therein.  
>>This would remove the logic of mapping vcpus to cpus from the 
>>hypervisor and let the dom creation tools build whatever 
>>algorithm for distributing vcpus across cpus as it sees fit.
>>    
>>
>
>Sure - feel free to remove the logic from Xen. It's simply there because
>until recently xend didn't know about number of hyperthreads, cores,
>sockets etc.
>
>  
>
I always thought that the so called logic in createdom is not very
clever and really doesn't belong there, although it has improved! It is
basically just something to get the domain going. Finer control is based
on xm pincpu. It would be more reasonable to give Xen a cpumask, already
when creating the domain. Rather than creating it and then setting the
cpumask immediatelly with xm pincpu...

>The default should be to give Xen considerable freedom in how it
>schedules VCPUs to CPUs: Stephan's load balancer is almost ready for
>posting.
>
>We should have some higher-level allocation control that can be tweaked
>in xend e,g, "don't use hyperthreading", "allow only privileged domains
>to use the 1st hyperthread on each CPU", "allow any logical CPU to be
>used by any VCPU". [All additionally subject to cpu-dedicate
>restrictions]
>  
>
Which could IMHO all expressed at a lower level (i.e. towards Xen) with
the cpumask.

>Does it actually need a change to the hypercall interface? The domain
>builder can just issue a pin for each VCPU. It might be cleaner to
>remove the orignal CPU field, but that's such a small change we should
>just do it anyway.
>  
>
I think the passing of the cpumask needs a little change in the code.

>We could remove the current default allocation code from Xen.
>  
>
Absolutely true.

Stephan

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