Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 978ADC6379F for ; Thu, 23 Feb 2023 08:27:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233610AbjBWI1T (ORCPT ); Thu, 23 Feb 2023 03:27:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52674 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232802AbjBWI1Q (ORCPT ); Thu, 23 Feb 2023 03:27:16 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D71584AFD5; Thu, 23 Feb 2023 00:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=R1GIMlyP5PmQ6SSQoioYTffHvrdpX2DoA1X1TWCwifQ=; b=jS9dsEsb5Fd/0eEkO0zUtow29J o5wgECtpniTBjdA+Vb0yrmQPVKc2v8KOZHZTyVVbtgyaibYrMJU9ZBpGg+TMVh/IkLkWabfplx+Br tmO+FrxbsBNroteuBOZUTbZjhfgxSlWczot+KzJ8kZnWY43ZtNv0Ky68OTsKb2/X19u8lNwemqdeF Qi/AsX8fwFYr1FQOZCQgKZb6AE2hl1rNf86uTdhXvbKb4/OVH47bpyQQYIgZoiQj1H7vm/tTzl+tb mU0rS+kkPKl6pIQBaFJHMsj2q3uf2YsceGb70dXOQw62BFBSp+goy/3u4Go25kRBviu5U49H+kC1o 2X2QkhFA==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1pV6wW-00ECNn-Jw; Thu, 23 Feb 2023 08:27:09 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 942BF30013F; Thu, 23 Feb 2023 09:27:07 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 3025620831B67; Thu, 23 Feb 2023 09:27:07 +0100 (CET) Date: Thu, 23 Feb 2023 09:27:07 +0100 From: Peter Zijlstra To: Atish Patra Cc: linux-perf-users@vger.kernel.org, "linux-kernel@vger.kernel.org List" , "mark.rutland@arm.com" , Beeman Strong , Anup Patel , linux-riscv Subject: Re: Perf event to counter mapping question Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 22, 2023 at 04:28:36PM -0800, Atish Patra wrote: > AFAIK, ARM64 allows all-to-all mapping in pmuv3[1]. That makes life > much easier. It just needs to pick the next available counter. > On the other hand, x86 allows selective counter mapping which is > discovered from the json file and maintained in per event > constraints[4]. All the contraint management is done in kernel, and yes, it's a giant pain in the rear side. From what I understand the reason for these contraints is complexity of implementation, less constraints is more 'wires' in the hardware. With PMU use being ever more popular, we're seeing the x86 PMU move towards less constraints -- although I don't think we'll ever get rid of them :/ > 2. Mandate all-to-all mapping similar to ARM64. If at all possible, I would strongly recommend taking this route. Yes, the hardware people will complain, but newer x86 hardware having less, or simpler, constraints might be sufficient to convince them. (and if you do have to do contraints, please take a lesson from x86 and *never* allow overlapping contraints as AMD had, solving those constraints is not fun) As you note, this is *much* simpler to program and virtualize. > Note: This is only for programmable counters. If the platform supports > any fixed counters (i.e. can monitor > only a specific event), that needs to be provisioned via some other > method. IIRC the fixed counters(apart from cycle) in ARM64 are part of > AMU not PMU. So free running counters are ideal and fairly simple to multiplex/use. The moment you start adding overflow interrupts / filters and any other complexities to fixed function counters it becomes a mess (look at the x86 PMU again).