From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryan Harper Subject: Re: [PATCH][RESUBMIT] don't schedule unplugged vcpus Date: Wed, 8 Jun 2005 16:52:44 -0500 Message-ID: <20050608215244.GF13586@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline 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@lists.xensource.com List-Id: xen-devel@lists.xenproject.org * Ian Pratt [2005-06-08 16:44]: > > I've added in changes to DOM0_GETDOMINFO and > > DOM0_GETVCPUCONTEXT hypercalls. dominfo now creates a > > vcpu_online_map bitmap which marks whether vcpus are up or > > down. I didn't want to clobber either the total number of > > vcpus allocated to a domain (n_vcpu) nor the vcpu_to_cpu > > mapping since both are still valid whether the vcpu is being > > scheduled or not. > > I don't see why we care about vcpus that are down. From the user's point > of view they've gone for good -- it just happens that Xen hasn't freed > the memory in anticipation of it being used again. What do you think? I don't think the users care so much as I want tools to be able to extract the current state of affairs for load balancing or other operations that want to account for domain state. > > I'd be inclined just to enter '-1' in the vcpu_to_cpu map. BTW: we could > make it an s16 rather than s32 at the same time. I think 32,768 CPUs > should keep be enough for anyone :-) Sure. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh@us.ibm.com