From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by ozlabs.org (Postfix) with ESMTP id 9E23E67A73 for ; Tue, 4 Apr 2006 04:08:44 +1000 (EST) Date: Mon, 3 Apr 2006 11:08:38 -0700 (PDT) From: Christoph Lameter To: Nathan Lynch Subject: Re: Fw: 2.6.16 crashes when running numastat on p575 In-Reply-To: <20060403180131.GD25663@localdomain> Message-ID: References: <20060402213216.2e61b74e.akpm@osdl.org> <20060402221513.96f05bdc.pj@sgi.com> <20060403141027.GB25663@localdomain> <20060403180131.GD25663@localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Christoph Lameter Cc: akpm@osdl.org, linuxppc-dev@ozlabs.org, pj@sgi.com, ak@suse.com, linux-kernel@vger.kernel.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, 3 Apr 2006, Nathan Lynch wrote: > > There are many other for_each_*_cpu loops in the kernel that do not have > > any of the instrumentation you suggest. I suggest you come up with a > > general solution and then go through all of them and fix this. Please be > > aware that many of these loops are performance critical. > > But this one isn't, right? Right. One could use more expensive processing here. > And I'm afraid there's a misunderstanding here -- only > for_each_online_cpu (or accessing the cpu online map in general) has > such restrictions -- for_each_possible_cpu doesn't require any locking > or preempt tricks since cpu_possible_map must not change after boot. Correct. We may want to audit the kernel and check that each for_each_possible_cpu or for_each_cpu is really correct. Developers frequently assume that all processors are up. There may be some complicated interactions with cpusets. Adding Paul to this. However, note that I am not interested hotplug functionality. It is going to be a difficult task to make the kernel shutdown processors correctly. I can give you feedback but I am not going to do this work.