Messages in this thread | | | Date | Fri, 17 May 2013 10:54:23 +0100 | From | Will Deacon <> | Subject | Re: [Bug] ARM 'perf' regression by commit a43cb95d5 |
| |
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@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.
> > > > 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)?
Will
| |