Re: Linux kernel arm oprofile driver compilation problem

[Peter Robinson <pbrobinson@xxxxxxxxx>]

Hi Will,

We now have a 3.3 kernel compiled, I'll test it over the weekend, thanks!

Peter

On Thu, Feb 23, 2012 at 1:35 PM, William Cohen <wcohen@xxxxxxxxxx> wrote:
> On 02/23/2012 05:12 AM, Will Deacon wrote:
>> Hi Will,
>>
>> On Thu, Feb 23, 2012 at 04:08:23AM +0000, William Cohen wrote:
>>>
>>> I was looking to see why the arm kernel builds for fedora 17 were failing with:
>>>
>>> arch/arm/oprofile/../../../drivers/oprofile/oprofile_perf.c:28:28: error: variably modified 'perf_events' at file scope
>>>
>>> The error points to the following line in oprofile_perf.c:
>>>
>>> static struct perf_event **perf_events[nr_cpumask_bits];
>>>
>>> The nr_cpumask_bits is defined in linux/include/linux/cpumask.h with
>>> the following snippet of code:
>>>
>>> #if NR_CPUS == 1
>>> #define nr_cpu_ids              1
>>> #else
>>> extern int nr_cpu_ids;
>>> #endif
>>>
>>> #ifdef CONFIG_CPUMASK_OFFSTACK
>>> /* Assuming NR_CPUS is huge, a runtime limit is more efficient.  Also,
>>>  * not all bits may be allocated. */
>>> #define nr_cpumask_bits nr_cpu_ids
>>> #else
>>> #define nr_cpumask_bits NR_CPUS
>>> #endif
>>>
>>> The problem is that several arm machines have more than one processor
>>> (CONFIG_NR_CPUS>1), making nr_cpumask_bits be a variable rather than a
>>> compile time constant.  Seems like the kernel should dynamically allocate
>>> space for perf_events[nr_cpumask_bits] because of the variable nature
>>> of nr_cpu_mask_bits.
>>
>> That or use NR_CPUS instead (which will be the same as nr_cpu_ids on ARM).
>>
>> One thing I'm curious about is why you have CONFIG_CPUMASK_OFFSTACK selected
>> for the Fedora kernel? That implies you have DEBUG_PER_CPU_MAPS selected
>> which, according to Kconfig, `adds a fair amount of code to kernel memory
>> and decreases performance'.
>>
>> Cheers,
>>
>> Will
>
> When I was building kernels locally I didn't see this problem because of:
>
> # CONFIG_DEBUG_PER_CPU_MAPS is not set
>
> So adding that to the config-arm-generic of the kenrel source rpm, should be a work around for this problem.
>
> -Will
> _______________________________________________
> arm mailing list
> arm@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/arm
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm