On Sun, Jul 10, 2016 at 12:03:41PM -0700, tip-bot for Ingo Molnar wrote: > Commit-ID: 44530d588e142a96cf0cd345a7cb8911c4f88720 > Gitweb: http://git.kernel.org/tip/44530d588e142a96cf0cd345a7cb8911c4f88720 > Author: Ingo Molnar <mingo@xxxxxxxxxx> > AuthorDate: Sun, 10 Jul 2016 20:58:36 +0200 > Committer: Ingo Molnar <mingo@xxxxxxxxxx> > CommitDate: Sun, 10 Jul 2016 20:58:36 +0200 > > Revert "perf/x86/intel, watchdog: Switch NMI watchdog to ref cycles on x86" > > This reverts commit 2c95afc1e83d93fac3be6923465e1753c2c53b0a. > > Stephane reported the following regression: > > > Since Andi added: > > > > commit 2c95afc1e83d93fac3be6923465e1753c2c53b0a > > Author: Andi Kleen <ak@xxxxxxxxxxxxxxx> > > Date: Thu Jun 9 06:14:38 2016 -0700 > > > > perf/x86/intel, watchdog: Switch NMI watchdog to ref cycles on x86 > > > > $ perf stat -e ref-cycles ls > > <not counted> .... > > > > fails systematically because the ref-cycles is now used by the > > watchdog and given this is a system-wide pinned event, it monopolizes > > the fixed counter 2 which is the only counter able to measure this event. > > Since the next merge window is near, fix the regression for now > by reverting the commit. I don't think there is any better solution than the original patch. The NMI watchdog taking up the precious cycle counter (which is far more important than the obscure ref cycles) was always a big problem because it prevents any groups running that need it. A lot of tools, including now perf stat --topdown now cannot deal with it without adding extra multiplexing which totally destroys the measurements on non steady state workloads. So I would prefer to not revert it. If you want ref-cycles you can just disable the NMI watchdog. Today most people who use cycles in non trivial situations have to do that. With ref-cycles still some people have to do it, but it's far less common than before. So basically the revert is worse than what was there with the patch. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html