From: "Jan Beulich" Subject: Re: [PATCH] linux: don't bring up CPUs that can never be used Date: Mon, 14 Aug 2006 16:05:58 +0200 Message-ID: <44E09F66.76E4.0078.0@novell.com> References: <44E09586.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline 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 , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> I'm a little bit wary of the second hunk. Although it's probably okay, >> is it >>> actually required? Looks like the first hunk is what fixes the issue. >> >> It's probably not strictly required, but sill better than iterating >> over NR_CPUS, as >> that is what mainline is in the process of phasing out. The only >> difference I can >> see to the results of the original code is that for cpu 0 the two array >> members >> now also get (re-)initialized here - but the value stored should be the >> same as >> may have been stored earlier. > >If it's true that those maps only get interrogated for CPUs in the >cpu_online_map, could we remove that loop altogether? We initialise the map >entries for CPUs as they're brought online in __cpu_up(): should that >suffice? I think considering cpu_possible_map/cpu_present_map would be safer here, which is why I made the loop run over cpu_present_map. __cpu_up wouldn't be sufficient for setting this up then. I am, however, not sure whether these maps ever get accessed for non-online CPUs, so your suggestion might well work. Jan