Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754504AbbFKNDL (ORCPT ); Thu, 11 Jun 2015 09:03:11 -0400 Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:38458 "EHLO e06smtp13.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752462AbbFKNDC (ORCPT ); Thu, 11 Jun 2015 09:03:02 -0400 Date: Thu, 11 Jun 2015 15:02:55 +0200 From: Hendrik Brueckner To: Peter Zijlstra Cc: Hendrik Brueckner , Ingo Molnar , Arnaldo Carvalho de Melo , Vince Weaver , Paul Mackerras , Martin Schwidefsky , Heiko Carstens , linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org Subject: Re: [PATCH 1/2] perf: return ENOENT instead of ENOTSUPP Message-ID: <20150611130255.GA4636@linux.vnet.ibm.com> Mail-Followup-To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Vince Weaver , Paul Mackerras , Martin Schwidefsky , Heiko Carstens , linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org References: <1434016745-17608-1-git-send-email-brueckner@linux.vnet.ibm.com> <1434018301.1495.73.camel@twins> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1434018301.1495.73.camel@twins> User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15061113-0013-0000-0000-000004538B0A Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2721 Lines: 69 On Thu, Jun 11, 2015 at 12:25:01PM +0200, Peter Zijlstra wrote: > On Thu, 2015-06-11 at 11:59 +0200, Hendrik Brueckner wrote: > > The ENOTSUPP (which actually should be EOPNOTSUPP for user space) does not > > trigger a fallback event selection, for example, by perf record. > > If hardware support for the cycles perf event is available, but the hardware > > does not provide interrupts, returning ENOTSUPP causes perf to end. Returning > > ENOENT causes the perf tool to fallback to a software-based cycle PMU that > > supports interrupts. > > > > The commit 53b25335dd ("perf: Disable sampled events if no PMU interrupt") > > introduced that incompatible change. > > That's 3.16 Correct... I recently encountered the problem. > > > if (event->pmu->capabilities & PERF_PMU_CAP_NO_INTERRUPT) { > > - err = -ENOTSUPP; > > + err = -ENOENT; > > goto err_alloc; > > } > > } > > And now you would be changing an API that's been around for at least 4 > releases. Well... the behavior before 53b25335dd was differently in this regard. Of course, the API changed 4 releases ago. The question here is rather was this desired or not. In my mind I considered this problem as a regression. > > Also, I really think -ENOENT is the wrong return here, you're asking for > things that's not supported, not for something that's not there. So looks like -ENOTSUPP is the desired API now. So the problem I'd like to solve is that there are two different hardware PMUs that support the "cycles" event. Just one of them supports sampling of cycles, the other not. In the past (prior to 3.16), the perf tool tried several PMUs if -ENOENT was returned. With 3.16, -ENOTSUPP is returned (which actually should be -EOPNOTSUPP but different story) and the perf tool exits. So the question is: what is the desired behavior? A solution towards the "fallback-behavior" would be to change perf_init_event() and consider the sampling/non-sampling criteria (in general pmu->capabilities) when looking for a matching PMU to serve the event? Thanks and kind regards, Hendrik -- Hendrik Brueckner brueckner@linux.vnet.ibm.com | IBM Deutschland Research & Development GmbH Linux on System z Development | Schoenaicher Str. 220, 71032 Boeblingen IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Koederitz Geschaeftsfuehrung: Dirk Wittkopp Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/