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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23A3CC433E0 for ; Mon, 15 Mar 2021 02:05:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ED45C64E46 for ; Mon, 15 Mar 2021 02:05:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229754AbhCOCFM (ORCPT ); Sun, 14 Mar 2021 22:05:12 -0400 Received: from mga02.intel.com ([134.134.136.20]:23747 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229696AbhCOCFG (ORCPT ); Sun, 14 Mar 2021 22:05:06 -0400 IronPort-SDR: QUXVDh1ZHkWAuaOs95zMm/4iRzeULlguPhHoRYaULBFGKOxeWpgY4BjR6yaPO7H75pBJYnTCF9 APKfsvJhL6cA== X-IronPort-AV: E=McAfee;i="6000,8403,9923"; a="176155359" X-IronPort-AV: E=Sophos;i="5.81,249,1610438400"; d="scan'208";a="176155359" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Mar 2021 19:05:03 -0700 IronPort-SDR: W1zli7DB7+Qnk5OSd8HjoSFwrLC4OEUoIt3ev9dbhSxdgHZwdrv9Uzd8PPt364vyJMu0Z7jYea u0h4LVMyZ9jw== X-IronPort-AV: E=Sophos;i="5.81,249,1610438400"; d="scan'208";a="411680328" Received: from yjin15-mobl1.ccr.corp.intel.com (HELO [10.238.4.6]) ([10.238.4.6]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Mar 2021 19:04:58 -0700 Subject: Re: [PATCH v2 09/27] perf parse-events: Create two hybrid hardware events To: Jiri Olsa Cc: acme@kernel.org, jolsa@kernel.org, peterz@infradead.org, mingo@redhat.com, alexander.shishkin@linux.intel.com, Linux-kernel@vger.kernel.org, ak@linux.intel.com, kan.liang@intel.com, yao.jin@intel.com References: <20210311070742.9318-1-yao.jin@linux.intel.com> <20210311070742.9318-10-yao.jin@linux.intel.com> From: "Jin, Yao" Message-ID: <65b8208c-ac5d-bdea-a11a-64d4a3d29562@linux.intel.com> Date: Mon, 15 Mar 2021 10:04:56 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jiri, On 3/13/2021 3:15 AM, Jiri Olsa wrote: > On Thu, Mar 11, 2021 at 03:07:24PM +0800, Jin Yao wrote: > > SNIP > >> cycles: 4: 800933425 1002536659 1002536659 >> cycles: 5: 800928573 1002528386 1002528386 >> cycles: 6: 800924347 1002520527 1002520527 >> cycles: 7: 800922009 1002513176 1002513176 >> cycles: 8: 800919624 1002507326 1002507326 >> cycles: 9: 800917204 1002500663 1002500663 >> cycles: 10: 802096579 1002494280 1002494280 >> cycles: 11: 802093770 1002486404 1002486404 >> cycles: 12: 803284338 1002479491 1002479491 >> cycles: 13: 803277609 1002469777 1002469777 >> cycles: 14: 800875902 1002458861 1002458861 >> cycles: 15: 800873241 1002451350 1002451350 >> cycles: 0: 800837379 1002444645 1002444645 >> cycles: 1: 800833400 1002438505 1002438505 >> cycles: 2: 800829291 1002433698 1002433698 >> cycles: 3: 800824390 1002427584 1002427584 >> cycles: 4: 800819360 1002422099 1002422099 >> cycles: 5: 800814787 1002415845 1002415845 >> cycles: 6: 800810125 1002410301 1002410301 >> cycles: 7: 800791893 1002386845 1002386845 >> cycles: 12855737722 16040169029 16040169029 >> cycles: 6406560625 8019379522 8019379522 >> >> Performance counter stats for 'system wide': >> >> 12,855,737,722 cpu_core/cycles/ >> 6,406,560,625 cpu_atom/cycles/ > > so we do that no_merge stuff for uncore pmus, why can't we do > that in here? that'd seems like generic way > > jirka > We have set the "stat_config.no_merge = true;" in "[PATCH v2 08/27] perf stat: Uniquify hybrid event name". For hybrid hardware events, they have different configs. The config is 0xDD000000AA (0x400000000 for core vs. 0xa00000000 for atom in this example) We use perf_pmu__for_each_hybrid_pmu() to iterate all hybrid PMUs, generate the configs and create the evsels for each hybrid PMU. This logic and the code are not complex and easy to understand. Uncore looks complicated. It has uncore alias concept which is for different PMUs but with same prefix. Such as "uncore_cbox" for "uncore_cbox_0" to "uncore_cbox_9". But the uncore alias concept doesn't apply to hybrid pmu (we just have "cpu_core" and "cpu_atom" here). And actually I also don't want to mix the core stuff with uncore stuff, that would be hard for understanding. Perhaps I misunderstand, correct me if I'm wrong. Thanks Jin Yao