Messages in this thread | | | Date | Fri, 17 May 2013 18:07:37 +0800 | Subject | Re: [Bug] ARM 'perf' regression by commit a43cb95d5 | From | Ming Lei <> |
| |
On Fri, May 17, 2013 at 5:54 PM, Will Deacon <will.deacon@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@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
| |