This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] RE: [Xen-users] Xen 3.0 Dom0 Smp enable?
From: Stephan Diestelhorst <sd386@xxxxxxxxxxxx>
Date: Mon, 08 Aug 2005 18:31:55 +0100
Cc: Ryan Harper <ryanh@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Alan Greenspan <alan@xxxxxxxxxxx>
Delivery-date: Mon, 08 Aug 2005 17:30:03 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D2829ED@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D2829ED@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)
>>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
>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
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.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>