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 17:12:47 -0500 Message-ID: <20050608221247.GH13586@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 17:00]: > > > 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 think the vcpu_to_cpu map contains that. OK. I had started doing that, but something stopped me, though I can't recall what it was at the moment. I'll mark the down vcpus in the vcpu_to_cpu map and see if I recall what I thought was objectionable. > The n_vcpu variable isn't really needed: my inclination would be to just > report the number that are currently up, though I'm not hugely fussed. That is an easy change, and we can revert to keeping n_vcpu to the number of valid vcpus per domain if there in fact is a need. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh@us.ibm.com