On Fri, May 17, 2013 at 10:27:05AM +0100, Ming Lei wrote: > On Fri, May 17, 2013 at 4:55 PM, Will Deacon <will.dea...@arm.com> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/