From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH for-4.6 2/3] xl: fix vNUMA vcpus parsing Date: Thu, 13 Aug 2015 10:42:26 +0100 Message-ID: <1439458946.23981.43.camel@citrix.com> References: <1439408161-15015-1-git-send-email-wei.liu2@citrix.com> <1439408161-15015-3-git-send-email-wei.liu2@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZPp1q-0005uo-81 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2015 09:42:30 +0000 In-Reply-To: <1439408161-15015-3-git-send-email-wei.liu2@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu , Xen-devel Cc: Dario Faggioli , Ian Jackson , Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org On Wed, 2015-08-12 at 20:36 +0100, Wei Liu wrote: > Originally, if user didn't specify maxvcpus= in xl config file, the > maximum size of vcpu bitmap was always equal to maximum number of pcpus. > This might not be what user wants. What are you suggesting they wanted instead? We are only talking about the bitmap right, and the typical/sensible config will have #vcpus <= #pcpus, so they will fit even if they "waste" some bits during parsing. I'm almost inclined to suggest that if a user wants #vcpus > #pcpus they should have to specify maxvcpus and not rely on the vnuma parsing code inferring this fact. IOW maybe this code could just error out (or print a warning) if this happens? + a doc update. > Calculate the maximum number of vcpus before allocating vcpu bitmap. > This requires parsing the same config options twice. Extra a macro to do > that. I'm not sure a macro was really the right answer here. e.g. a function which takes a pointer to a bitmap, if the bitmap is null return the size which would be needed, otherwise fill in the bitmap, or something. That could also be split more obviously into a refactoring step and then the addition of the new checks. > Signed-off-by: Wei Liu > --- > Valgrind is still clean after this patch applied. > > This patch looks massive because it involves indentation changes, but in > fact the meat of it is small. Even with -b it's impossible to read. Ian.