From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B7D4DEA; Tue, 12 Dec 2023 10:49:25 -0800 (PST) Received: by mail-pj1-f48.google.com with SMTP id 98e67ed59e1d1-2866af9d73bso4274508a91.3; Tue, 12 Dec 2023 10:49:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702406965; x=1703011765; h=content-transfer-encoding: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=ieLFoul+mPd07DhlmLbEOA93lnztioXfkR7OG/Df+DA=; b=bAcc2eIzWeoo3OBxHov2eG3v9sOKkirmyvwy2vzWOyv25FliibRP0Q9VpbP6xQ0Sd2 6LVXnKeIHP47XKcJuF6O17MpXG3+yUxPiuxpigXHrN7MYQvMiXsDeXToo2aBJRwbwg6o HzFff+Sy/JEKk+Bn7txemmIyyKRrEyabunGs9gbJUo7iyW0078y8HT6dmNAaZZs2oJYG HvEJ6kAKfDL1FtrN5VpB9cSz7FsYhPQstkn+/nzx2Qred318rw+I7Ub8SyxfZmxZgO9d IGmNlPX65GRa2JCOQ7LhwLqDiqTKFuwQUfAW0RVRIJlu+OSK/vJumwqHjSahi8+4S4tq mOLg== X-Gm-Message-State: AOJu0YzYnKHWrs2pZZW2+OWGXstGxcFFdUD8R7/7gtpN6cKcuaP3hjZp t0J/0Ijbp0Z5RhCND0jONx9h/pz16Z2hQEKHvJs= X-Google-Smtp-Source: AGHT+IHdP3JrLMVcqtMfuENRl0xtVa+FaokLT1DzuYhAg4/9SPuXyOZnu4rxOzqkQLlNZeaWchecIL4bXQ7nH+WRKrQ= X-Received: by 2002:a17:90b:1210:b0:28a:6137:149b with SMTP id gl16-20020a17090b121000b0028a6137149bmr2980031pjb.94.1702406965050; Tue, 12 Dec 2023 10:49:25 -0800 (PST) Precedence: bulk X-Mailing-List: linux-perf-users@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20231208210855.407580-1-kan.liang@linux.intel.com> <07677ab2-c29b-499b-b473-f7535fb27a8c@linux.intel.com> In-Reply-To: From: Namhyung Kim Date: Tue, 12 Dec 2023 10:49:13 -0800 Message-ID: Subject: Re: [PATCH] perf top: Use evsel's cpus to replace user_requested_cpus To: Mark Rutland Cc: Ian Rogers , "Liang, Kan" , Arnaldo Carvalho de Melo , maz@kernel.org, marcan@marcan.st, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 12, 2023 at 10:31=E2=80=AFAM Mark Rutland wrote: > > On Tue, Dec 12, 2023 at 10:00:16AM -0800, Ian Rogers wrote: > > On Tue, Dec 12, 2023 at 9:23=E2=80=AFAM Namhyung Kim wrote: > > > > > > On Tue, Dec 12, 2023 at 7:56=E2=80=AFAM Liang, Kan wrote: > > > > > > > > > > > > > > > > On 2023-12-11 4:13 p.m., Arnaldo Carvalho de Melo wrote: > > > > > Em Fri, Dec 08, 2023 at 01:08:55PM -0800, kan.liang@linux.intel.c= om escreveu: > > > > >> From: Kan Liang > > > > >> > > > > >> perf top errors out on a hybrid machine > > > > >> $perf top > > > > >> > > > > >> Error: > > > > >> The cycles:P event is not supported. > > > > >> > > > > >> The user_requested_cpus may contain CPUs that are invalid for a = hybrid > > > > >> PMU. It causes perf_event_open to fail. > > > > > > > > > > ? > > > > > > > > > > All perf top expects is that the "cycles", the most basic one, be > > > > > collected, on all CPUs in the system. > > > > > > > > > > > > > Yes, but for hybrid there is no single "cycles" event which can cov= er > > > > all CPUs. > > > > > > Does that mean the kernel would reject the legacy "cycles" event > > > on hybrid CPUs? > > > > I believe not. When the extended type isn't set on legacy cycles we > > often have the CPU and from that can determine the PMU. The issue is > > with the -1 any CPU perf_event_open option. As I was told, the PMU the > > event is opened on in this case is the first one registered in the > > kernel, on Intel hybrid this could be cpu_core or cpu_atom.. but IIRC > > it'll probably be cpu_core. On ARM =C2=AF\_(=E3=83=84)_/=C2=AF. > > On ARM it'll be essentially the same as on x86: if you open an event with > type=3D=3DPERF_EVENT_TYPE_HARDWARE (without the extended HW type pointing= to a > specific PMU), and with cpu=3D=3D-1, it'll go to an arbitrary CPU PMU, wh= ichever > happens to be found by perf_init_event() when iterating over the 'pmus' l= ist. > > If you open an event with type=3D=3DPERF_EVENT_TYPE_HARDWARE and cpu!=3D-= 1, the event > will opened on the appropriate CPU PMU, by virtue of being rejected by ot= hers > when perf_init_event() iterates over the 'pmus' list. Ok, that means "cycles" with cpu =3D=3D -1 would not work well. I'm curious if it's possible to do some basic work at the event_init() like to preserve (common) resource and to do some other work at sched to config PMU on the current CPU. So that users can simply use "cycles" or "instructions" for their processes. Thanks, Namhyung