Page MenuHomeFreeBSD

Support of optional PMC classes.
ClosedPublic

Authored by ray on Oct 5 2021, 2:07 PM.
Tags
Referenced Files
Unknown Object (File)
Mon, Apr 8, 5:00 AM
Unknown Object (File)
Thu, Apr 4, 5:19 AM
Unknown Object (File)
Tue, Mar 26, 5:35 PM
Unknown Object (File)
Jan 16 2024, 11:38 AM
Unknown Object (File)
Dec 20 2023, 7:27 AM
Unknown Object (File)
Dec 11 2023, 6:08 AM
Unknown Object (File)
Nov 23 2023, 2:11 PM
Unknown Object (File)
Nov 23 2023, 6:46 AM
Subscribers

Details

Summary

Some PMU controllers are standalone and not bound to CPU. So classes of such controllers can be optional and in case when optional class in the middle of machine-dependent class list it must be skipped.

Sponsored By: Ampere Computing

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

ray requested review of this revision.Oct 5 2021, 2:07 PM
ray retitled this revision from Support of optional classes. to Support of optional PMC classes..Oct 5 2021, 2:23 PM
ray edited the summary of this revision. (Show Details)
ray added reviewers: pmc, mhorne.
ray added a project: pmc.
ray edited the summary of this revision. (Show Details)

Update classes base ri to handle optional classes out of order.

It seems to me that only the changes to pmc_arm64_initialize() should be necessary, because it handles optional classes in the same way that pmc_intel_initialize() does, by passing the correct nclasses value to pmc_mdep_alloc().

sys/dev/hwpmc/hwpmc_mod.c
5770–5771

How can such an optional class appear in this list? It seems like it shouldn't happen, because you take care to call pmc_mdep_alloc() with the correct nclasses value.

It seems to me that only the changes to pmc_arm64_initialize() should be necessary, because it handles optional classes in the same way that pmc_intel_initialize() does, by passing the correct nclasses value to pmc_mdep_alloc().

Problem here is in static machdep class numbers. If classes will be initialized in incorrect order, adjusted ri will be incorrect. So that modification may save some time on debugging such issue for new optional classes with just little time in hwpmc(4) init.

In D32316#737883, @ray wrote:

It seems to me that only the changes to pmc_arm64_initialize() should be necessary, because it handles optional classes in the same way that pmc_intel_initialize() does, by passing the correct nclasses value to pmc_mdep_alloc().

Problem here is in static machdep class numbers. If classes will be initialized in incorrect order, adjusted ri will be incorrect. So that modification may save some time on debugging such issue for new optional classes with just little time in hwpmc(4) init.

Ahh right, so it handles the case where you have a dmc620 but not a cmn600. This looks good to me then.

This revision is now accepted and ready to land.Oct 27 2021, 3:39 PM

@ray I assume you can go ahead with committing this one?

@ray I assume you can go ahead with committing this one?

Fortunately I did not execute your assumption :)
Because here is not committed class identifiers.
But thanks for reminder!

sys/dev/hwpmc/hwpmc_mod.c
5770–5771

For example, one of classes fail to initialize. It have to be present in a list, otherwise class number and array position will not match. But to not process that class we can check number of counters it add (0 here).

This revision was automatically updated to reflect the committed changes.