Representing Topology

Topology shows the structure of the system by expressing relationships between system resources. The statistics store represents system topology by combining multiple canonical resource names, where a canonical resource name is a class, res pair. The last canonical name in the SSID is the name of the resource whose topology is described by the SSID. A //:class after a //:res is a topological link to related resources. If you are not familiar with the structure of the system, these SSIDs can help you explore the topology.

Topology mapping can also provide a more user-friendly SSID by omitting implementation details. For example, statistics from the kstat or dtrace providers might be mapped to providers such as cpu or disk.

Often a topology is valid only for a specific time period because events such as failures and hotplug operations change the configuration of a system. To explore past topology, specify the time range with the sstore export command as shown in Using Command Line Interfaces.

The following SSIDs show that this system has only one processor set and one chip but has four cores and four CPUs. All pset and chip resource values are id/0, while core and cpu resources values are id/0, id/1, id/2, and id/3.

$ sstore list //:class.cpu//:res.*//:class.*//:res.*
IDENTIFIER
//:class.cpu//:res.id/0//:class.chip//:res.id/0
//:class.cpu//:res.id/0//:class.core//:res.id/0
//:class.cpu//:res.id/0//:class.pset//:res.id/0
//:class.cpu//:res.id/1//:class.chip//:res.id/0
//:class.cpu//:res.id/1//:class.core//:res.id/1
//:class.cpu//:res.id/1//:class.pset//:res.id/0
//:class.cpu//:res.id/2//:class.chip//:res.id/0
//:class.cpu//:res.id/2//:class.core//:res.id/2
//:class.cpu//:res.id/2//:class.pset//:res.id/0
//:class.cpu//:res.id/3//:class.chip//:res.id/0
//:class.cpu//:res.id/3//:class.core//:res.id/3
//:class.cpu//:res.id/3//:class.pset//:res.id/0

The following command shows an alternative way to explore relationships among cores, chips, and CPUs. The previous example shows that CPUs have cores, chips, and processor sets. The following example shows that cores have chips and CPUs.

$ sstore list //:class.core//:res.id/*//:*//:*
IDENTIFIER
//:class.core//:res.id/0//:class.chip//:res.id/0
//:class.core//:res.id/0//:class.cpu//:res.id/0
//:class.core//:res.id/1//:class.chip//:res.id/0
//:class.core//:res.id/1//:class.cpu//:res.id/1
//:class.core//:res.id/2//:class.chip//:res.id/0
//:class.core//:res.id/2//:class.cpu//:res.id/2
//:class.core//:res.id/3//:class.chip//:res.id/0
//:class.core//:res.id/3//:class.cpu//:res.id/3
//:class.core//:res.id/2//:class.cpu//:res.id/2

The following command confirms that these SSIDs are topology links:

$ sstore info //:class.core//:res.id/2//:class.cpu//:res.id/2
 Identifier: //:class.core//:res.id/2//:class.cpu//:res.id/2
  stability: stable
description: topology link
$ sstore info //:class.cpu//:res.id/3//:class.core//:res.id/3
 Identifier: //:class.cpu//:res.id/3//:class.core//:res.id/3
  stability: stable
description: topology link

You can query statistics and events by specifying only the last canonical resource name in the SSID, as shown by the following comparison:

$ sstore list //:class.core//:res.id/2//:class.cpu//:res.id/2//:*
IDENTIFIER
//:class.core//:res.id/2//:class.cpu//:res.id/2//:class.chip
//:class.core//:res.id/2//:class.cpu//:res.id/2//:class.core
//:class.core//:res.id/2//:class.cpu//:res.id/2//:class.pset
//:class.core//:res.id/2//:class.cpu//:res.id/2//:event.adm-action
//:class.core//:res.id/2//:class.cpu//:res.id/2//:event.fault
//:class.core//:res.id/2//:class.cpu//:res.id/2//:stat.usage
//:class.core//:res.id/2//:class.cpu//:res.id/2//:stat.interrupt-count
//:class.core//:res.id/2//:class.cpu//:res.id/2//:stat.interrupt-time
//:class.core//:res.id/2//:class.cpu//:res.id/2//:stat.xcalls
$ sstore list //:class.cpu//:res.id/2//:*
IDENTIFIER
//:class.cpu//:res.id/2//:class.chip
//:class.cpu//:res.id/2//:class.core
//:class.cpu//:res.id/2//:class.pset
//:class.cpu//:res.id/2//:event.adm-action
//:class.cpu//:res.id/2//:event.fault
//:class.cpu//:res.id/2//:stat.usage
//:class.cpu//:res.id/2//:stat.interrupt-count
//:class.cpu//:res.id/2//:stat.interrupt-time
//:class.cpu//:res.id/2//:stat.xcalls