From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH v5 2/8] xenalyze: increase NR_CPUS to 256 Date: Mon, 15 Jun 2015 18:14:51 +0200 Message-ID: <20150615161451.GA29475@aepfle.de> References: <1433849019-27452-1-git-send-email-olaf@aepfle.de> <1433849019-27452-3-git-send-email-olaf@aepfle.de> <55789E1C.9030504@citrix.com> <20150611061226.GA22268@aepfle.de> <55796B1C.9020309@citrix.com> <55799CBA.3020005@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <55799CBA.3020005@eu.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: George Dunlap Cc: Wei Liu , Ian Campbell , Stefano Stabellini , Ian Jackson , xen-devel@lists.xen.org, Julien Grall List-Id: xen-devel@lists.xenproject.org On Thu, Jun 11, George Dunlap wrote: > On 06/11/2015 12:03 PM, Julien Grall wrote: > > I would suggest some refactoring to remove NR_CPUS and associated code > > in order to avoid mis-usage later. > > > > Also, cpu_mask_t is a uint32_t, is it intentional? > > When xenalyze was originally written back in 2006, I think that's > probably how it was defined in Xen. I just haven't used it on a system > with more than 32 cpus. :-) > > That certainly should be addressed at some point. I'd be in favor of > checking this in and fixing it up later; or, for the time being, just > disabling the skew detection functionality (which is the only place that > uses it, AFAICT). Today I looked at this part: In v6 I have added a patch to remove cpumask_t. Now I see xenalyze.c has a cpu_mask_t with just 32 bits. Easy change would be to change that to uin64_t. To really support MAX_CPUS the code can either include xen/include/xen/cpumask.h, or just the few required functions can be pasted into xenalyze.c. What do you prefer? Olaf