From mboxrd@z Thu Jan 1 00:00:00 1970 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 D44FEC433FE for ; Fri, 20 May 2022 17:28:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351932AbiETR2h (ORCPT ); Fri, 20 May 2022 13:28:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237887AbiETR2b (ORCPT ); Fri, 20 May 2022 13:28:31 -0400 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 306BE17D399 for ; Fri, 20 May 2022 10:28:30 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id u27so11576262wru.8 for ; Fri, 20 May 2022 10:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PlBrfFXLkcBjzvaU5ZE61p8d0548/U8plsIcnYc6nwM=; b=AmbYVUjm1Vvk52XX+gT8m9nyVd9UytuO7zSN8e691d+mbvoHmjsMc3RLNZylvOQYEd zVzN2oVZE5VSxSZ0ETLdp1LjgvBp4qRgPDMzDPAVIU0gpQVTswTvQECG8uwX066LpKKI YEIRmDtjNrpaO3W4dM2Ky78GbZkwkzyF2vpuDPED4OCG9qDL3saqa+x6tp8L6DuVhM59 QbK5RBe3Cq/eVInec37zHdr3yFJ3c9xUJRYg2uiKRtowHai8bi6VAsjGu3EFmt6GffUt lnrtvgFNmq5JClrkBHf7tNeCTeBQMw6mCfTlR54dmHw6YlJUZ2DGyB3juoK/oBhcIZ4E m0PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PlBrfFXLkcBjzvaU5ZE61p8d0548/U8plsIcnYc6nwM=; b=LE/sxkjNJNwils9/pUBzHLA4qcQqYZseNpOfOty5o/xzI1rkP/MMnecpoobM2HEoXf D1O8Jk1H7CP/qQklhuGA33LprKjvxPZh3D1P7YVXbEPfSOZB5Uc5/rHYZsOD+QxDtQ0J rFomXe/YIlUbNGPSLpHzNILrRwb+2qmZQ6yGuGqtf++KwlL+RLKuPx1qiFE9sgE59qkq FBdSDUD2dXSRBddfLY6fHy6/U9QPjDD7irFMYuLlwL10tZ50bF4qU4ZOi/AtXf4ijU0X z/1MIg3XYVPuzWkoKUL+h3De50L+SIatKtN1uZSH9ihj1EtBIj/KcGJPZ+3QyzS0tTtd YwLA== X-Gm-Message-State: AOAM532bDcX/l2luYE++S9IKgA5bxqOh1kUcd4t80JKfG1wDJQWgy0Cs 2Af/fBTYRskTPWiw7WaNwWxEUo5yWXNjsRbWm7uB2Q== X-Google-Smtp-Source: ABdhPJz+I2ODFYGbdO1VhcQmaC6u7o1kmBPfNUDweJO4khAF66jihI5X7p3fHMS8kkj/hBJpwYFY/Rjm2u34bv5Uw+k= X-Received: by 2002:a5d:448d:0:b0:20d:744:7663 with SMTP id j13-20020a5d448d000000b0020d07447663mr9282426wrq.654.1653067708557; Fri, 20 May 2022 10:28:28 -0700 (PDT) MIME-Version: 1.0 References: <20220510104758.64677-1-nick.forrington@arm.com> <28509191-3a45-de6d-f5bc-a8e7331c0a9e@huawei.com> <5773b630-8159-1eba-481a-1bf3c406c055@arm.com> <7a17256d-cad0-bd94-02e7-f8adaa959654@arm.com> <2d73146a-86fc-e0d1-11b9-432c7431d58a@huawei.com> In-Reply-To: From: Ian Rogers Date: Fri, 20 May 2022 10:28:16 -0700 Message-ID: Subject: Re: [PATCH 00/20] perf vendors events arm64: Multiple Arm CPUs To: Nick Forrington Cc: John Garry , Robin Murphy , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, acme@kernel.org, Will Deacon , Mathieu Poirier , Leo Yan , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Andi Kleen , Kajol Jain , James Clark , Andrew Kilroy Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 19, 2022 at 6:53 AM Nick Forrington wrote: > > > On 19/05/2022 08:59, John Garry wrote: > > On 18/05/2022 15:14, Robin Murphy wrote: > >>> Sure, we should have these 32b cores supported for ARCH=arm if they > >>> are supported for ARCH=arm64. But then does it even make sense to > >>> have A7 support in arch/arm64? > >> > >> That's what I'm getting at. If it is tied to the build target as > >> you've said above, then there is no point in an AArch64 perf tool > >> including data for CPUs on which that tool cannot possibly run; it's > >> simply a waste of space. > >> > >> If there is interest in plumbing in support on AArch32 builds as > >> well, then I'd still be inclined to have a single arch/arm events > >> directory, and either do some build-time path munging or just symlink > >> an arch/arm64 sibling back to it. Yes, technically there are > >> AArch64-only CPUs whose data would then be redundant when building > >> for AArch32, > > > > If size is an issue then we have ways to cut this down, like doing the > > arch standard events fixup dynamically when running perf tool, or even > > not describing those events in the JSONs and rely on reading the CPU > > PMU events folder to learn which of those events are supported. > > > > > but those are > > > such a minority that it seems like an entirely reasonable compromise. > > > > @Nick, Can you drop the 32b core support for arm64? Or, if you really > > want them, look into ARCH=arm pmu-events support? > > No problem - I'll resubmit without the 32b-only CPUs. > > Thanks, > Nick > I'm hoping with jevents.py [1] then we can do a few things on the size front: 1) relocations - the current pattern of generating '.foo = "foo_Bar"' means that when perf starts the .foo pointer needs to be updated for the relocation. If we concatenate the strings together then we can have 1 relocation, but we'll need an offset and length to get .foo's value and some kind of iteration abstraction. If we do this then we could also look to compress the string at compile time. 2) sorting events - not really a compiler size improvement but should lower some runtime memory usage. We shouldn't need to linearly search event names, sorting at compile time means we can locate faster, less paging, etc. 3) we've spoken in the past of the problems of cross-architecture testing of events, metrics, etc. For metrics, we may want to record events on one architecture and compute metrics on another. One idea is to have a fuller jevents mode where everything is built into one binary, which would make size improvements more valuable. Another thing with jevents.py is trying to make the pmu-events.c presentation more consistent with sysfs', which may regress things on size. Anyway, I think it is good to have more events and I'm excited to see this merged in a way that's suitable for John. I'm happy to do more optionality stuff with jevents.py or the build if that can mean having more events on ARM32. Thanks, Ian [1] https://lore.kernel.org/linux-perf-users/20220511211526.1021908-1-irogers@google.com/ - show your love with Acked-bys :-D