[Bug 257641] hwpmc/libpmc needs to gain a notion of big.LITTLE

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257641

Stefan Eßer <se@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |se@FreeBSD.org

--- Comment #1 from Stefan Eßer <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 applicable
cpuset. You can deal with both system-scope and process-scope PMCs in exactly
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. 

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 user
might compare different runs with different PMCs without being aware that some
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 again
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 option
of pmcstat) support it.

It might be a good idea to somehow report the supported PMCs to the userland 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 names).
That would make it possible to list the core numbers that allow some specific
measurement, for example, without the user remembering all details of the CPU.

-- 
You are receiving this mail because:
You are the assignee for the bug.