Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1061239pxf; Thu, 18 Mar 2021 19:50:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw/BoHf44lthkbbyeZmQE6OV38ZBms/azhjG4X+g+ArZmQjyzXi0qPCEonjsT0uBeBS9vT0 X-Received: by 2002:a05:6402:27d4:: with SMTP id c20mr7195459ede.271.1616122228764; Thu, 18 Mar 2021 19:50:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616122228; cv=none; d=google.com; s=arc-20160816; b=zxdKL0Q48Y329M1MLjdyFZ8sF1LfaR4erFJutwc6GyrS87/PLz3QzCCIALmCd7q0+1 14Tg91jna034HdHRyNh5J13NftY5mbfooF4xn4+DDI8tMOsUMLAT/MdHxAWjeJA5GN4c gNvsEBduiKNcpcZDYdmlvZN+fATf29kFRKF6zYgxS/Wme6LyRP5BRA3MoSn1xq09RDB1 Oht/XeuvWbSxyfJGMsahZsHsBwalawHR9nEVuME5GDiPUy2xKY2GCuNgEoKNy+FxZrN0 QpMzp9V7UsAZwlI1q770D45uDPaZDzHYdcf/dz7zQHDIMTWNhPf2cQAUQ28JnRHsCdtq chaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:ironport-sdr :ironport-sdr; bh=y9ne/xmX8GifzYVLxmvJk3vFgu8+aZC8lRkZGhmflsM=; b=P7scwRWbSHsIFc+0zLpr7AtIqV/kaddqiuHizP69FDGqhGINE1Y3Y5QuRULEk9JDTs fwElBhWV0nCLA4ymMBLrAQ9vctVxvWzr5tOnolT3x2a4CqfI1VU/Z8yLvhsNsp61Wc5w jy3/y/PTttMeL+//TdToJNfjdPPhSZTpSITz9tihaadXeLImDH1SZEPUYRdEp8agZ0XE a11EwSQxmxM5fn8XTRTZ+IyW9DuesRB8l2Xv9IUjlPRA34nPkgClm7pDu/Fv7hxmAIQR xweAbkDggqUhVkWO5S27/DVRKqKor2+HJu80Tmbf/49yZT68GaBMbjdqtjrGi2MB0m61 deRw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g26si3041833edr.573.2021.03.18.19.50.06; Thu, 18 Mar 2021 19:50:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230332AbhCSCsw (ORCPT + 99 others); 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