From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephan Diestelhorst Subject: Re: RE: [Xen-users] Xen 3.0 Dom0 Smp enable? Date: Mon, 08 Aug 2005 18:31:55 +0100 Message-ID: <42F7970B.30407@cl.cam.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: Ryan Harper , xen-devel , Alan Greenspan List-Id: xen-devel@lists.xenproject.org >>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