From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751983AbcFFK3G (ORCPT ); Mon, 6 Jun 2016 06:29:06 -0400 Received: from merlin.infradead.org ([205.233.59.134]:54321 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751313AbcFFK3D (ORCPT ); Mon, 6 Jun 2016 06:29:03 -0400 Date: Mon, 6 Jun 2016 12:29:00 +0200 From: Peter Zijlstra To: Christian Borntraeger , linux-s390 , "linux-kernel@vger.kernel.org >> Linux Kernel Mailing List" Subject: Re: 4.7-rc1/s390: WARNING: CPU: 5 PID: 1 at kernel/events/core.c:8485 perf_pmu_register+0x420/0x428 Message-ID: <20160606102900.GC30909@twins.programming.kicks-ass.net> References: <201606060737.u567YMPJ012970@mx0a-001b2d01.pphosted.com> <20160606082124.GA30154@twins.programming.kicks-ass.net> <201606060929.u569T8fW028400@mx0a-001b2d01.pphosted.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201606060929.u569T8fW028400@mx0a-001b2d01.pphosted.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 06, 2016 at 11:29:36AM +0200, Hendrik Brueckner wrote: > > > Looks like perf_pmu_register does not like to be called twice (once for the counter > > > and once for the sampling facility). > > > > Twice isn't the problem per se, its trying to register two PMUs for > > perf_hw_context that is the problem. > > > > The perf core does not expect or deal well with that. > > > > The perf core expects a single HW PMU in that when it schedules > > hw_context events, and encounters an failure to pmu::add() (because the > > hw pmu is 'full') it stops trying to add more events. > > On s390, there are actually two distinct measurement facilities and, thus, > two HW PMUs for each. There is the hardware counter and hardware sampling > facility/PMU. Can you quickly describe the cf one; or provide a link to a document doing so? If this is a simple always running counter without interrupt you could make it a 'software' PMU which can always schedule, similar to the x86 MSR driver (arch/x86/events/msr.c).