From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753429AbYI0Aqc (ORCPT ); Fri, 26 Sep 2008 20:46:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751648AbYI0AqY (ORCPT ); Fri, 26 Sep 2008 20:46:24 -0400 Received: from relay2.sgi.com ([192.48.171.30]:52450 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751465AbYI0AqX (ORCPT ); Fri, 26 Sep 2008 20:46:23 -0400 Message-ID: <48DD8263.8020205@sgi.com> Date: Fri, 26 Sep 2008 17:46:27 -0700 From: Mike Travis User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: Steven Rostedt CC: Peter Zijlstra , LKML , Ingo Molnar , Thomas Gleixner , Andrew Morton , prasad@linux.vnet.ibm.com, Linus Torvalds , Mathieu Desnoyers , "Frank Ch. Eigler" , David Wilder , hch@lst.de, Martin Bligh , Christoph Hellwig , Masami Hiramatsu , Steven Rostedt , Arnaldo Carvalho de Melo Subject: Re: [PATCH v6] Unified trace buffer References: <20080925185154.230259579@goodmis.org> <20080925185236.244343232@goodmis.org> <48DC406D.1050508@redhat.com> <1222456474.16700.289.camel@lappy.programming.kicks-ass.net> <48DD61F4.3000704@sgi.com> <48DD78C6.5030701@sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Steven Rostedt wrote: > On Fri, 26 Sep 2008, Mike Travis wrote: >> Steven Rostedt wrote: >>>> The other thing to consider is using a percpu variable. >>> This structure is allocated on request. >>> >>> -- Steve >> >> Ahh, then it would need the yet to be added cpu_alloc() from Christoph. > > We can always change this later. > >> Your best bet then is to allocate based on nr_cpu_ids. > > Actually in this case I chose num_possible_cpus(). Reason being is that > later I may add an interface to allow the user to select which CPUs they > want to trace, and this will only allocate a subset of CPU buffers. > (not going to implement that in the first release). > > But to lay the ground work, I set a buffers->cpumask to be that of all the > cpus with buffers allocated. For now that mask is set to cpu_possible_map. > Since num_possible_cpus() is defined as cpus_weight_nr(cpu_possible_map) > I figured that was the better choice. > > -- Steve One problem though, it's *theoretically* possible for num_possible to be less than nr_cpu_ids and a cpu index may extend past the end of your allocated array. This would happen if the cpu indices are allocated some other way than as each cpu is discovered. For example, a system might want a group of cpus in one section (say by node, or socket) and then a hole in the cpu_possible_map until the next group. nr_cpu_ids is guaranteed to be the highest possible cpu + 1. Cheers, Mike