From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753307AbcCALG4 (ORCPT ); Tue, 1 Mar 2016 06:06:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48307 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752460AbcCALGz (ORCPT ); Tue, 1 Mar 2016 06:06:55 -0500 Date: Tue, 1 Mar 2016 12:06:51 +0100 From: Jiri Olsa To: Peter Zijlstra Cc: "Liang, Kan" , 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: <20160301110651.GA15260@krava.redhat.com> References: <20160227123636.GB30858@krava.redhat.com> <37D7C6CF3E00A74B8858931C1DB2F0770589EC94@SHSMSX103.ccr.corp.intel.com> <20160301091703.GN6356@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160301091703.GN6356@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 01, 2016 at 10:17:03AM +0100, Peter Zijlstra wrote: > 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? ] im on it.. also the patch that makes this happen just enlarge the buffer for PEBS: 156174999dd1 perf/intel/x86: Enlarge the PEBS buffer but I did not find anyaPEBS buffer lenght limitations in SDM jirka > > 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.