Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp6757346rdb; Fri, 15 Dec 2023 07:36:23 -0800 (PST) X-Google-Smtp-Source: AGHT+IHR3odcrEvT7wUSwFkxXVUx2uKpmXgozME998z+Xw6+zfAStkiCHBQOpviNkVPbrQoxEyng X-Received: by 2002:a9d:7349:0:b0:6d8:4e1d:7723 with SMTP id l9-20020a9d7349000000b006d84e1d7723mr9107806otk.20.1702654582959; Fri, 15 Dec 2023 07:36:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702654582; cv=none; d=google.com; s=arc-20160816; b=XQXEbCD65ZJwIFmDSSM2LYhtmf4460UoszRKEpbEEW76ayBtzTo4l+uYRIhDadjOYW /H0AA3+pJiVfnZu01lN4gVS0zgyyx4WkEwyVQzo1IsKj1vNNHJSP3KzCd7TJbC2nUkGY QiXeqDS3dMgJmOBg7uVtR9RcNI87aIcoH8JMR2uG3OCC6oA9eu2F23dg9CgN+C1Pfeyh B/+qXgdT0oK/j6vuupd8AbTxvpRjN5SNLS0QZyefpXnoilWAij422c47qIysCF1CbwXu icHmj8rqmiF+OVS4wD8jkrQLqIDIfyUs86cGnu8F+64QV1+P0eS53fW3mM/uet1D/ei6 b0XA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=KTsaCBPltBLKvnaZ0DuXYsOydq/7uy/KgJZmj6sHGWY=; fh=rEh9ZhlsfdxtOwTRfy2Of3dZ0u0PbWdsWh0No/yDS0g=; b=KwdVO24JpuOYlkyDUnWlrGUKby8PJDKDrHUU8l01Wk4+PW2Sx9UBgjMNLiOQjP7l+p xGrIrQhsttqi43kduvv5vag34KtEM54cyxe9nYVHAZsFQ9GT4NwcNaer9rttphWlwoJT DGcMHZTjhSZq0JPsmg8xZ4aOiPI+Dwwa4uNZTkcd6PkojsgiLU5GjxzKkKkxi4RK208O v2GxrGE2Zq0z77BjQniEkBfMUiTdn9YsR0EiqacwFxht5jrvMS04EXW6h4bUyfh1T6fL oMRRQiqDaqsvU7dELKZST8Db/nbmFbq56UVYhv0P2nzUepx0qaChYYxAttt6dkKTjh99 GcVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=EbvWMx9j; spf=pass (google.com: domain of linux-kernel+bounces-1219-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1219-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id c3-20020ab03483000000b007cb14b305aesi2085193uar.17.2023.12.15.07.36.22 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Dec 2023 07:36:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-1219-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=EbvWMx9j; spf=pass (google.com: domain of linux-kernel+bounces-1219-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1219-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id A47BA1C23190 for ; Fri, 15 Dec 2023 15:36:22 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6B0CC37165; Fri, 15 Dec 2023 15:36:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EbvWMx9j" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9EF62320F; Fri, 15 Dec 2023 15:36:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DEF33C433C8; Fri, 15 Dec 2023 15:36:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702654574; bh=QkGYnpI7VkJ6ZnApbfPGjqcENeC9oxa/+M+iQlRNTew=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EbvWMx9j+qVNefKJn+Tr/6Z/qq08iInLITOqy0GNB2BK7LRoYq/VbHLGCxWh34XOu hHgO1q5YeGHFdHw3T9N8ra22CZbt7QVjrdax1BmOz6H+qRhexQWu1H6jBiVMOig5Dk U0bARE8E1aunSOR3F6K4vdv1dYodmm164F//QhohX8VQlNKMfSDY8bNnnwQA//hp2l I1NBq4qLGDXjnktrRtA5+UAxMAKO7UBa+iWKBdwjbRXDst33bPxtYR2yhuXfMvKIrb 0UenvZqev54cr74MWAghqpnjC2ZX+b1UWPPUh+GGQO2q187B7NZK0Mzbtlifb5mK1N m5lVdS0QFzrdA== Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id B4F8A403EF; Fri, 15 Dec 2023 12:36:10 -0300 (-03) Date: Fri, 15 Dec 2023 12:36:10 -0300 From: Arnaldo Carvalho de Melo To: Mark Rutland , "Liang, Kan" Cc: Ian Rogers , Namhyung Kim , maz@kernel.org, marcan@marcan.st, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org Subject: Re: [PATCH] perf top: Use evsel's cpus to replace user_requested_cpus Message-ID: References: <20231208210855.407580-1-kan.liang@linux.intel.com> <07677ab2-c29b-499b-b473-f7535fb27a8c@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Url: http://acmel.wordpress.com Em Tue, Dec 12, 2023 at 06:31:05PM +0000, Mark Rutland escreveu: > On ARM it'll be essentially the same as on x86: if you open an event with > type==PERF_EVENT_TYPE_HARDWARE (without the extended HW type pointing to a > specific PMU), and with cpu==-1, it'll go to an arbitrary CPU PMU, whichever > happens to be found by perf_init_event() when iterating over the 'pmus' list. > If you open an event with type==PERF_EVENT_TYPE_HARDWARE and cpu!=-1, the event > will opened on the appropriate CPU PMU, by virtue of being rejected by others > when perf_init_event() iterates over the 'pmus' list. The way that it is working non on my intel hybrid system, with Kan's patch, is equivalent to using this on the RK3399pc board I have: root@roc-rk3399-pc:~# perf top -e armv8_cortex_a72/cycles/P,armv8_cortex_a53/cycles/P Wouldn't be better to make 'perf top' on ARM work the way is being done in x86 now, i.e. default to opening the two events, one per PMU and allow the user to switch back and forth using the TUI/stdio? Kan, I also noticed that the name of the event is: 1K cpu_atom/cycles:P/ ◆ 11K cpu_core/cycles:P/ If I try to use that on the command line: root@number:~# perf top -e cpu_atom/cycles:P/ event syntax error: 'cpu_atom/cycles:P/' \___ Bad event or PMU Unable to find PMU or event on a PMU of 'cpu_atom' Initial error: event syntax error: 'cpu_atom/cycles:P/' \___ unknown term 'cycles:P' for pmu 'cpu_atom' valid terms: event,pc,edge,offcore_rsp,ldlat,inv,umask,cmask,config,config1,config2,config3,name,period,freq,branch_type,time,call-graph,stack-size,no-inherit,inherit,max-stack,nr,no-overwrite,overwrite,driver-config,percore,aux-output,aux-sample-size,metric-id,raw,legacy-cache,hardware Run 'perf list' for a list of valid events Usage: perf top [] -e, --event event selector. use 'perf list' to list available events root@number:~# It should be: "cpu_atom/cycles/P" - Arnaldo