Date: Fri, 06 Aug 2021 09:26:31 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 257641] hwpmc/libpmc needs to gain a notion of big.LITTLE Message-ID: <bug-257641-227-dNX5Y215gb@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-257641-227@https.bugs.freebsd.org/bugzilla/> References: <bug-257641-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257641 Stefan E=C3=9Fer <se@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |se@FreeBSD.org --- Comment #1 from Stefan E=C3=9Fer <se@FreeBSD.org> --- Maybe the best solution is to just have a per-core check for validity of the requested PMC and verify that it is available on *all* CPUs in the applicab= le cpuset. You can deal with both system-scope and process-scope PMCs in exact= ly the same way, then. This will obviously require a list of supported PMC register number ranges = per architecture attached to the per-core data. By formalizing a format (e.g. a range of start,end values) the check could become MI. For process-scope PMCs the user has to explicitly specify a cpuset that excludes the cores that do not support the PMC, giving him full control over the measured setup. If the process is not bound only to cores that support = the PMC, the request must be rejected.=20 An implicit cpuset() to limit the process-scope PMC to use just those cores that support some particular PMC might give surprising results, since the u= ser might compare different runs with different PMCs without being aware that s= ome of them were measured on a limited set of cores and the others on all cores. In the case of system-scope PMCs you may be able to request one PMC on cores that support it and another less optimal PMC on cores that don't. To support such a use case, the selection of cores to use for the measurement should a= gain be explicit and based on core numbers (i.e., not just implicitly based on whether a core supports the requested PMC). In either case I'd reject the request if not all selected cores (cpuset of = the process to monitor, currently active cpuset, or cores selected by the -c op= tion of pmcstat) support it. It might be a good idea to somehow report the supported PMCs to the userlan= d by means of dev.cpu sysctl variables. These could either identify the core architecture or just provide a list of supported PMC register numbers as a string (e.g. in the style of "1,5-10" or perhaps as a list of register name= s). That would make it possible to list the core numbers that allow some specif= ic measurement, for example, without the user remembering all details of the C= PU. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-257641-227-dNX5Y215gb>