Performance Counter and Core

Since SPARC III, HW counter, High resoluation timer and virtual clock address the most
efficient to deliver the most accurate performance data. However, it will be a major limitation
to access performance within NG-Zone with the introduction of the S10 container technology.
Therefore, the traditional counter approach may be challenged by the latest virtualization and
partition service requirements.

However, system monitoring is driven by serveral major factors:
status check, performance tunning, debugging and troubleshooting

Majority system management is not required by debugging and tunning level performance resolutions.

In addition, all HW counter requires kernel based accessing. libcpc(3LIB) is one of the performance coutner library for uts cpu_t structure. The same issues as libkstat(3LIB), cpustat(1M) , cputrack(1M) CLI call routines and realetd user land structure associated with chip_id, cpuid, status which lacks of core support. Moreover, the same libkstat(3LIB) kstat_data_lookup for kstat_t and kstat_named_t are required to be handled.

I could not see the major gain for libcpc(3LIB) either in terms of the limitation of performance counter,core support, and dependency on libkstat(3LIB).

Just for sharing, libkstat(3LIB) requires execute Kernel
static library call routines as /on/usr/src/cmd to
open /dev/kstat and kstat_lookup to uses existing
common user land kstat_t strcutre Afterwards,
kstat_data_lookup should be invoked to downcast
to kstat_named_t in order to retrieve the exported
templated cpu_info structure for "core_id" and
KSTAT_DATA_LONE value.

It just reinvent the same call routines as any (1M) CLI at user
lande. I did not see any value of doing so. In addition, HP and
BMC will have their own user lander structure and object model
to abstract and management objects.

The major work for HP OV and BMC patrol should focus on is to
design the object class to redegin the object model for MIB II
in order to fit the architecture needs.