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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 DF723C433E0 for ; Fri, 19 Mar 2021 02:49:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A371F64E10 for ; Fri, 19 Mar 2021 02:49:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231558AbhCSCsw (ORCPT ); Thu, 18 Mar 2021 22:48:52 -0400 Received: from mga14.intel.com ([192.55.52.115]:8831 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230108AbhCSCsm (ORCPT ); Thu, 18 Mar 2021 22:48:42 -0400 IronPort-SDR: 9bxn5N2bizQM9kMGNPUH7M8G91aEkPqOduuiQRq9uxiOW5lXzMxg3w+7zMYoLrLcYLvFs1ZxUq PWw0ZIRppjSw== X-IronPort-AV: E=McAfee;i="6000,8403,9927"; a="189191512" X-IronPort-AV: E=Sophos;i="5.81,259,1610438400"; d="scan'208";a="189191512" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2021 19:48:32 -0700 IronPort-SDR: 0egM2ZIpY/Clb562h/dSheMwRjoccsD20Ck2Ebt0xPuvtClzzmatJ0XcgRJwReY5gxXlU1qsxa PM+G06UaJv0Q== X-IronPort-AV: E=Sophos;i="5.81,259,1610438400"; d="scan'208";a="512343375" Received: from tassilo.jf.intel.com ([10.54.74.11]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2021 19:48:32 -0700 Date: Thu, 18 Mar 2021 19:48:30 -0700 From: Andi Kleen To: Arnaldo Carvalho de Melo Cc: "Jin, Yao" , Jiri Olsa , jolsa@kernel.org, peterz@infradead.org, mingo@redhat.com, alexander.shishkin@linux.intel.com, Linux-kernel@vger.kernel.org, kan.liang@intel.com, yao.jin@intel.com Subject: Re: [PATCH v2 11/27] perf parse-events: Support hardware events inside PMU Message-ID: <20210319024830.GC1369306@tassilo.jf.intel.com> References: <20210311070742.9318-12-yao.jin@linux.intel.com> <65624432-2752-8381-d299-9b48ec508406@linux.intel.com> 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 > While we're discussing, do we really want to use the "core" and "atom" > terms here? I thought cpu/cycles/ would be ok for the main (Big) CPU and Yes absolutely. > that we should come up with some short name for the "litle" CPUs. There actually isn't a main CPU. There's nothing "better" about the big cores vs the Atoms anyways. They're all important CPUs. And the system might have no "big" CPUs, but we won't know until we finished onlining all CPUs. Or on Lakefield there are four Atoms and only a single big core. So with a non hybrid aware profiler tool you would miss most of the system if we used cpu// for the big core. Also I think renaming is a good idea because it forces the software or configuration to handle hybrid. Otherwise you just get subtle breakage all the time with some CPUs not getting profiled. It's a similar strategy as we do in the source code when semantics change. ARM did this right. -Andi