From nobody Thu Aug 05 17:35:35 2021 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BFB9C11DD754 for ; Thu, 5 Aug 2021 17:35:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GgbNl50XTz3QjB for ; Thu, 5 Aug 2021 17:35:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9445D1E8EF for ; Thu, 5 Aug 2021 17:35:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 175HZZRY081335 for ; Thu, 5 Aug 2021 17:35:35 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 175HZZrE081334 for bugs@FreeBSD.org; Thu, 5 Aug 2021 17:35:35 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 257641] hwpmc/libpmc needs to gain a notion of big.LITTLE Date: Thu, 05 Aug 2021 17:35:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mhorne@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257641 Bug ID: 257641 Summary: hwpmc/libpmc needs to gain a notion of big.LITTLE Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: mhorne@freebsd.org Some systems that FreeBSD supports contain a heterogeneous collection of CP= Us. This is present in ARM's big.LITTLE chips, such as the rockpro64, and will = be a feature of some next-generation x86 chips as well [1][2]. The PMC stack was written in a time before these heterogeneous systems, and thus the assumpti= on of homogeneous support for performance monitoring capabilities among all co= res in the system is ingrained. This is stated explicitly in the hwpmc(4) man p= age under IMPLEMENTATION NOTES. In the case of the rockpro64/RK3399, it contains four Cortex-a53 cores and = two larger Cortex-a72 cores. There is some overlap of supported performance eve= nts between the two types, but some events that are unique to each. This poses problems that hwpmc is not currently equipped to deal with. The first problem to solve is CPU reporting. There are two ways this is communicated from the kernel to libpmc, via the kern.hwpmc.cpuid sysctl and= the PMC_OP_GETCPUINFO operation on the hwpmc syscall. Neither of these methods = make a distinction between different CPUs in the system, so the value received by userspace basically depends on which CPU does the initialization of the hwp= mc module. This somehow needs to become a per-CPU value, in order to properly detect which events are supported on a given core. Assuming this is solved, the basic high-level behaviour will depend on the = type of PMC being allocated: System-scope PMCs: Allocating a system-scope counter with e.g. pmcstat -s will attempt= to allocate the event on every CPU in the system. If the allocation fails for = any CPU, the command will not proceed with any measurement. This has reasonable behaviour on a heterogeneous system, where the user needs to either pick an event that is compatible with all CPUs, or use the -c flag to qualify the selected CPUs. Process-scope PMCs: Allocating a process-scope counter is slightly more problematic. Suppose a = PMC counter is allocated on CPU A, where the target process is running and the requested event is supported. If the process is migrated to CPU B, which differs from A, then attempting to resume the hardware counter could start measuring an entirely different event, if the programmed value is valid at = all.=20 I see two possible ways to solve this: don't allow PMC-enabled processes (curproc->p_flag & P_HWPMC) to migrate outside of their PMC-compatible clus= ter, OR, have libpmc call cpuset(3) for the process, and bind it to compatible C= PUs for the duration of the measurement. I have not thought through either of t= hese approaches in detail, but both require building some list of "PMC-compatibl= e" CPU groups/clusters in the kernel. [1] https://www.cnx-software.com/2021/07/10/intel-alder-lake-hybrid-mobile-proc= essor-family-to-range-from-5w-to-55w-tdp/ [2] https://www.tomshardware.com/news/amd-patent-hybrid-cpu-rival-intel-raptor-= lake-cpu --=20 You are receiving this mail because: You are the assignee for the bug.=