Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp13000768rwb; Sat, 26 Nov 2022 20:27:40 -0800 (PST) X-Google-Smtp-Source: AA0mqf6+wsDQ5SLDMrgitgWr7D9rLyZzsuGocJn6TsEWOPz7roxamgpnBmQGAFe6/9PeZTioaTgY X-Received: by 2002:a63:5042:0:b0:46f:e658:a8ff with SMTP id q2-20020a635042000000b0046fe658a8ffmr25910255pgl.493.1669523260003; Sat, 26 Nov 2022 20:27:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669523259; cv=none; d=google.com; s=arc-20160816; b=M9EMAlFebqc2ylVBFZrCc63mU7qV/CKSZ56ptoryTvcs19XlaAS8XcTXd4Blt2Rnpo HscWt7VffLYCGJ0TrPqHFDJvdnxJW5NpAjW/AoBVzQGK9S35IzsOtYi0nsslMOeLqSYC q06ABRGw0Q1p7dEioR0ckVi+FM3XHle1CNOR1oW4psh7sPMldmMy6Zdi59/RvjHwIHis x7bDd9mNCsttCpr6AhOFRmxZuvqW+e2cGYshValitAuZTlsV+oIJ2+PYbBR9kzhxjSyk mKtR4UEHkKwfT3gv3uAmai29j0FQxi7jKxapOSLCHOFrHBRbtTaO4s8pLS1+Qu0G7bcJ HNpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=B7jJJzGDAdvwTHY0/uqqYf6jkjFWmT8EU2xpYpvXkds=; b=hb5bMwFYJczMeVgYl0obIkG+uMfJOmFpjVV8PD2ZZlQ+4qL3ZOZsS+yweHzl0NaW2v sBttGBkb6KUcUu8sh978hNuoghOBG0ihoyoXp6zhaJTZXET5Ae1QUHUjtiFOCz4xPvJG O1/msrg1NTlYGWRMk6P6A5tXJkNPONN2SuGe0Q1eIs5eGmaOfoOcBonpypsdTielMPa0 JDIp/QwuDpSKwzuWmUqLL/IZQd/HhuJTK4RsioEdsh73QB7m42fCAVLlfpeFoBhvJdBm NFe45ll8hadBAgSEpZ4QEsj9TElGKrsQ6QtyaorXovlw2Prm3E38OWfKNhE/ghkJkY1z T7hQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=cePTeChG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 35-20020a631163000000b004707dd3280asi8480165pgr.204.2022.11.26.20.27.18; Sat, 26 Nov 2022 20:27:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=cePTeChG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229500AbiK0DOs (ORCPT + 85 others); Sat, 26 Nov 2022 22:14:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229453AbiK0DOr (ORCPT ); Sat, 26 Nov 2022 22:14:47 -0500 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 76435F5AB for ; Sat, 26 Nov 2022 19:14:45 -0800 (PST) Received: by mail-wm1-x32a.google.com with SMTP id ay14-20020a05600c1e0e00b003cf6ab34b61so9072444wmb.2 for ; Sat, 26 Nov 2022 19:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=B7jJJzGDAdvwTHY0/uqqYf6jkjFWmT8EU2xpYpvXkds=; b=cePTeChGShsKFQLKo60/NW160lCTvZ5UIrzkfSGokNE7LKlkvAKqCkVlqiSB10KNPE 8q1EoBmxueU34vR0QFvwtcqicOHoxW0GRYY69d1JNRddcLHtP9oZuM2MWykXPrj076S9 pm9oXtrQrft7qGK2r1rnDgk/jb89gR7RHXElUier3GlZ0Ga31EGMJVTpLwEKZr0zYGBe wDUazPxKe3j1G+BtMnZgHpxQhSYJd0JklCht9o6K3yi8A2xjl5AVBHpCGQi1EBV6MEb+ br+SgLKyfvmqRCtYdT/jbChq25oqeXmu8pX3S88Ni+J07UAb9iRnPOHuejNro3S2w5W7 kOxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=B7jJJzGDAdvwTHY0/uqqYf6jkjFWmT8EU2xpYpvXkds=; b=6xQBp2azoQJbsT40k862FkSj1RziW/1QeGj5jSsFDXMk5Nl9wiE4wpBinhY77BTOez vWcUeb7931z+p9Q91AczjvrQO2Nho3Ub/P9tchDKUmff+s/fF+8RXOlYc0h1239z0l/e U5CWczhGQBtwFmzznaZjbgsMLVgp6mj4LhlTE/vkG9yCKlJ/dDwXR0VZSIPi5YIYww8Z g9wfD/g9DQ21sYt3nm96NvtM8w4YJmQgTT5MlwO+T0GijPmW8kDqwu/H18ezUbViqzwk T7eM+NN137OBVatp8n64XcD8LuwHfsZiTS5cnOtyfBk6DhXJGfgZrm2LwShRBjtlm+ms KQLg== X-Gm-Message-State: ANoB5pkXbr5aQqppoeL82xZbZE3fvRXZ3nEQqXfHFkjNhps5eVGqKnOX 6wdu2/glsoUZETUUV94nBqI8yTqtsvDGXVviRYdhww== X-Received: by 2002:a05:600c:540a:b0:3d0:50c4:432c with SMTP id he10-20020a05600c540a00b003d050c4432cmr3448681wmb.67.1669518883874; Sat, 26 Nov 2022 19:14:43 -0800 (PST) MIME-Version: 1.0 References: <20221123180208.2068936-1-namhyung@kernel.org> <20221123180208.2068936-15-namhyung@kernel.org> In-Reply-To: From: Ian Rogers Date: Sat, 26 Nov 2022 19:14:31 -0800 Message-ID: Subject: Re: [PATCH 14/15] perf stat: Rename "aggregate-number" to "cpu-count" in JSON To: Namhyung Kim Cc: Arnaldo Carvalho de Melo , Jiri Olsa , Ingo Molnar , Peter Zijlstra , LKML , Adrian Hunter , linux-perf-users@vger.kernel.org, Kan Liang , Zhengjun Xing , James Clark , Athira Jajeev Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 24, 2022 at 11:51 PM Namhyung Kim wrote: > > Hi Ian, > > On Wed, Nov 23, 2022 at 3:31 PM Ian Rogers wrote: > > > > On Wed, Nov 23, 2022 at 10:02 AM Namhyung Kim wrote: > > > > > > As the JSON output has been broken for a little while, I guess there are > > > not many users. Let's rename the field to more intuitive one. :) > > > > I'm not sure cpu-count is accurate. For example, an uncore counter in > > a dual socket machine may have a CPU mask of "0, 36", ie one event per > > socket. The aggregate-number in this case I believe is 2. > > You're right. In case of uncore events, it can be confusing. But in some > sense it could be thought as cpu count as well since it aggregates the > result from two cpus anyway. :) > > Note that the aggregate-number (or cpu-count) is only printed if users > requested one of aggregation options like --per-socket or --per-core. > In your example, then it could print 1 for each socket. > > But I think uncore events are different from core events, and hopefully > they have separate instances for different sockets or something already. > That means it doesn't need to use those aggregation options for them. > > Also the CSV output uses "cpus" for the same information. It'd be nice > we could have consistency. So in the original patch from Claire she'd passed the name "number" through to the json from the stat code. Having an integer called "number" isn't exactly intention revealing - thank you for your clean up work! :-) I switched "number" to be "aggregate number" as the number comes from the "data" aggregated and the code refers to it as aggregate data. I think aggregate-number is more consistent with the code, and cpu-count would look strange in the uncore case above where the number of CPUs (really hyperthreads) is 72. Perhaps we should also be outputting the aggregation mode with the number. Anyway, I think for the patch series I'd prefer we skipped this one and kept the rest. Thanks, Ian > Namhyung