Re: [PATCH v6] Unified trace buffer

[Mike Travis]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/