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:00:04 -0500 Message-ID: <20050608220004.GG13586@us.ibm.com> References: <0e458b5371820d127c90ac838f760c9c@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <0e458b5371820d127c90ac838f760c9c@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Ian Pratt , xen-devel@lists.xensource.com, Ryan Harper List-Id: xen-devel@lists.xenproject.org * Keir Fraser [2005-06-08 16:57]: > > On 8 Jun 2005, at 22:42, Ian Pratt wrote: > > >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'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 :-) > > This is how I view it. We don't free the vcpu structure only because it > isn't reference counted. We can only be sure that noone has a reference > to the structure when the entire domain's refcnt falls to zero. Given > the small amount of memory involved, it's not worth the pain or > run-time cost of adding per-vcpu reference counts. > > So VCPU_down == invisible outside Xen. So, when I trigger a vcpu to go down via dom0 xm operation, I have to trust that it worked? I have no way of knowing at some point later which vcpus are up or down? I don't see any cost to this other than during the getdominfo hcall. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh@us.ibm.com