From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752674AbcCAJR0 (ORCPT ); Tue, 1 Mar 2016 04:17:26 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:49639 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751456AbcCAJRY (ORCPT ); Tue, 1 Mar 2016 04:17:24 -0500 Date: Tue, 1 Mar 2016 10:17:03 +0100 From: Peter Zijlstra To: "Liang, Kan" Cc: Jiri Olsa , Arnaldo Carvalho de Melo , Ingo Molnar , Andi Kleen , Stephane Eranian , Wang Nan , "zheng.z.yan@intel.com" , LKML Subject: Re: [BUG] Core2 cpu triggers hard lockup with perf test Message-ID: <20160301091703.GN6356@twins.programming.kicks-ass.net> References: <20160227123636.GB30858@krava.redhat.com> <37D7C6CF3E00A74B8858931C1DB2F0770589EC94@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F0770589EC94@SHSMSX103.ccr.corp.intel.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 29, 2016 at 10:12:08PM +0000, Liang, Kan wrote: > In SDM "18.4.4.4 Re-configuring PEBS Facilities" it mentioned that > a quiescent period is needed between stopping the prior event counting and > setting up a new PEBS event when software needs to reconfigure PEBS facilities. > The quiescent period is to allow any latent residual PEBS records to complete > its capture at their previously specified buffer address > That requirement only can be found in Core Microarchitecture. But that should apply to all (PEBS) event scheduling, not just the multi thing. Also very convenient that quiescent period is so well defined. How long should we wait, a day? > I think it may implies that there is some observed delay in writing PEBS buffer. Doesn't it explicitly state just that? > So if perf record precise hw event with very small period, the slow PEBS writing > may lockup the CPU. And I still don't see how this would explain a lockup in the MSR writes. [ Jiri, can you disable that stupid panic on hard lockup and let it run for a while, see if all the lockup msgs hit the same IP? Also, can you look where exactly that IP lives in the code? ] So I suspect it actually just did the PERF_GLOBAL_CTRL write, how else would the hardware watchdog trigger on that same CPU. After that, there's only BTS muck, which you're not using, so WTH is it actually stuck on? > If so, I think disabling the multiple pebs should be a good way. As said, this should affect any and all PEBS event scheduling, not just the multi stuff.