[Bug] ARM 'perf' regression by commit a43cb95d5

[Ming Lei]

On Fri, May 17, 2013 at 5:54 PM, Will Deacon <will.deacon at arm.com> wrote:
> On Fri, May 17, 2013 at 10:48:23AM +0100, Ming Lei wrote:
>> On Fri, May 17, 2013 at 5:36 PM, Will Deacon <will.deacon at arm.com> wrote:
>> >
>> > It's probably easier if you choose a workload, otherwise it's difficult to
>> > see what is `correct' and what is broken. For example, your broken output
>> > seems to be in the smsc95xx driver, so assumedly there's a bunch of
>> > networking going on whereas your other output is in cpuidle_enter_state.
>>
>> If all modules are removed, the result will become OK. And if I only insert one
>> module, the top sample will fall inside the only module, but I am sure
>> nothing is working on the symbols of the module.
>
> Can you check your dmesg please? I suppose the smsc95xx driver might be
> screaming about something and somehow the changes to the reg printing have
> made it get stuck.

If I insert only one useless module(such as, spi-altera.ko) on Pandaboard,
the top sample will fall inside the module of spi-altera, so it is nothing to
do with smsc95xx, also you can see the sampled top IP is an invalid address.

>
>> >
>> > We need an apples-for-apples comparison if you think there's a bug in the
>> > kernel. Can you try profiling hackbench or something?
>> >
>> >> Or could anyone else try to verify the problem on their own environment?
>> >
>> > How are you running perf top?
>>
>> sudo perf top
>
> ... and did hackbench make any difference (i.e. is the profile more stable)?

When hackbench is started, there is no much change compared with idle,
only another sample( 2.49%  [unknown]            [.] 0xb6f618a0) comes and
becomes top 2.

Thanks,
--
Ming Lei