Messages in this thread | | | Date | Fri, 26 Sep 2008 17:46:27 -0700 | From | Mike Travis <> | Subject | Re: [PATCH v6] Unified trace buffer |
| |
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
| |