From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Fri, 17 May 2013 10:54:23 +0100 Subject: [Bug] ARM 'perf' regression by commit a43cb95d5 In-Reply-To: References: <20130517085530.GB22992@mudshark.cambridge.arm.com> <20130517093616.GC23112@mudshark.cambridge.arm.com> Message-ID: <20130517095423.GD23112@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:48:23AM +0100, Ming Lei wrote: > On Fri, May 17, 2013 at 5:36 PM, Will Deacon 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