Page MenuHomeFreeBSD

Support of optional PMC classes.
ClosedPublic

Authored by ray on Oct 5 2021, 2:07 PM.
Tags
Referenced Files
F102594858: D32316.diff
Thu, Nov 14, 1:30 PM
Unknown Object (File)
Oct 14 2024, 8:36 PM
Unknown Object (File)
Oct 14 2024, 8:07 PM
Unknown Object (File)
Oct 1 2024, 7:51 AM
Unknown Object (File)
Sep 20 2024, 10:33 AM
Unknown Object (File)
Sep 20 2024, 4:10 AM
Unknown Object (File)
Sep 19 2024, 6:17 PM
Unknown Object (File)
Sep 14 2024, 2:27 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
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 42380
Build 39268: arc lint + arc unit

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
5757–5758

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
5757–5758

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.