From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Fri, 17 May 2013 10:36:16 +0100 Subject: [Bug] ARM 'perf' regression by commit a43cb95d5 In-Reply-To: References: <20130517085530.GB22992@mudshark.cambridge.arm.com> Message-ID: <20130517093616.GC23112@mudshark.cambridge.arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, May 17, 2013 at 10:27:05AM +0100, Ming Lei wrote: > On Fri, May 17, 2013 at 4:55 PM, Will Deacon wrote: > > > > So it's still the morning and I haven't had my coffee yet, but I'm really > > struggling to see what you're getting at. Why does this have anything to do > > with perf? > > I don't know, and I just report it out, :-) > > I found the problem days ago, and until yesterday I had one more hours to > git-bisect it, but the result is very frustrated. > > > > >> [1], 'perf top' mistaken output > >> Samples: 17K of event 'cpu-clock', Event count (approx.): 3516532661 > >> 97.51% [smsc95xx] [k] 0x013645b8 > >> 0.21% libc-2.15.so [.] strstr > >> 0.14% libc-2.15.so [.] strchr > >> 0.12% libc-2.15.so [.] strcmp > > > > [...] > > > >> [2], 'perf top' correct output > >> Samples: 46K of event 'cpu-clock', Event count (approx.): 937128704 > >> 96.44% [kernel] [k] cpuidle_enter_state > >> 0.19% libc-2.15.so [.] strstr > >> 0.16% [kernel] [k] kallsyms_expand_symbol.clone.0 > >> 0.13% [kernel] [k] _raw_spin_unlock_irq > > > > [...] > > > > Are you saying that the profile you're seeing is radically different, > > rather than there being some formatting error that I can't spot? If so, that > > Yes. > > > sounds really strange and I can't see how the patch you mention is to > > blame... > > > > If we want to persue this, I guess other obvious questions are: which kernel > > are you running? Does this affect multiple architectures (your diff only > > Either 3.10-rc1 or today's -next tree(3.10.0-rc1-next-20130516). > > > changes ARM)? What's the workload which you are profiling? > > I only tested it on Pandaboard, and no real workload, so you can see > cpuidle_enter_state is the top frequent symbol. 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. 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? Will