NAME¶

pmns - the performance metrics name space

SYNOPSIS¶

$PCP_VAR_DIR/pmns

DESCRIPTION¶

When using the Performance Metrics Programming Interface (PMAPI)of the Performance Co-Pilot (PCP),performance metrics are identified by an external name in ahierarchic Performance Metrics Name Space (PMNS), and aninternal identifier, the Performance Metric Identifier (PMID).

A PMNS specifies the association between a metric's name and its PMID.

A PMNS is defined on one or more ASCII source files.

Loading of a PMNS is done by callingpmLoadNameSpace(3)orpmLoadASCIINameSpace(3).

As of Version 3.10.3 of PCP,by default duplicate names for the same PMIDareallowed in the PMNS,althoughpmLoadASCIINameSpace(3)provides an alternative interface with user-defined controlover the processing of duplicate names in the PMNS.The external format for a PMNS conforms to the syntaxand semantics described in the following sections.

There is one default PMNS in the files below$PCP_VAR_DIR/pmns,although users and application developers are free tocreate and use alternate PMNS's.For an example of this, seethe PCP Tutorial in$PCP_DEMOS_DIR/Tutorial.

Although an application can callpmLoadNameSpace(3),normally this is only done directly for the-ncommand line option where an explicit root PMNS file is specified.Since PCP version 2 uses a distributed PMNS (see below),an application can extract PMNS information from ahost's PMCD or an archive. If the PMNS sourceis a version 1 archive (seePCPIntro(1)),however,then the local PMNS will be loaded using the path specified by theenvironment variablePMNS_DEFAULT.

DISTRIBUTEDPMNS¶

In PCP version 1, the PMNS functions in the API all operated ona PMNS loaded locally from a file. Since PCP version 2, however,PMNS functions may get the PMNS information remotely from a PMCDor directly from the meta data of an archive.

PROCESSINGFRAMEWORK¶

The PMNS specification is initially passed throughpmcpp(1).This means the following facilities may be used in the specification

+

C-style comments

+

#include directives

+

#define directives and macro substitution

+

conditional processing via#ifdef ... #endif, etc.

Whenpmcpp(1)is executed, the ``standard'' include directories are the current directory and$PCP_VAR_DIR/pmns.

The pre-processing withpmcpp(1)may be omitted in some cases where the PMNS is known tonotcontain anyC-style comments, preprocessor directives or macros. Refer to thedescriptions ofpmLoadASCIINameSpace(3)andpmLoadNameSpace(3)for details.

SYNTAX¶

The general syntax for a non-leaf node in the PMNS is as follows

pathname {


        name      [pmid]


        ...
}

Wherepathname is the full pathname from the root of the PMNS to this non-leaf node, with each component in the pathname separated by a ``.''. The root node for the PMNS must have the special name ``root'', but the common prefix ``root.'' must be omitted from all pathnames. Each component in the pathname must begin with an alphabetic character, and be followed by zero or more characters drawn from the alphabetics, the digits and the underscore ``_'') character. For alphabetic characters in a pathname component, upper and lower case are distinguished.

Non-leaf nodes in the PMNS may be defined in any order.

The descendent nodes are defined by the set ofnames, relative to the pathname of their parent non-leaf node. For the descendent nodes, leaf nodes have a pmid specification, non-leaf nodes do not. The syntax for the pmid specification has been chosen to help manage the allocation of PMIDs across disjoint and autonomous domains of administration and implementation. Each pmid consists of 3 integer parts, separated by colons, e.g. 14:27:11. This hierarchic numbering scheme is intended to mirror the implementation hierarchy of performance metric domain, metrics cluster (data structure or operational similarity) and individual metric. In practice, the two leading components are likely to be macros in the PMNS specification source, and pmcpp(1)will convert the macros to integers. These macros forthe initial components of thepmid are likely to be defined either in a standard include file, e.g. $PCP_VAR_DIR/pmns/stdpmid,or in the current source file.

To support dynamic metrics, where the existence of a metric is known toa PMDA, but not visible in the PMNS, a variant syntax for thepmid is supported, namely a domain number followed by asterisks for the other components of the pmid, e.g. 14:*:*. The corresponding metric name forms the root of a subtree of dynamic metric names defined in the corresponding PMDA as identified by the domain number.

The current allocation of the high-order (PMD or domain) componentof PMIDs is as follows.

EXAMPLE¶

#define KERNEL 1
#define FOO 387
root {


    network


    cpu


    dynamic     FOO:*:*
}
#define NETWORK 26
network {


    intrate     KERNEL:NETWORK:1


    packetrate
}
network.packetrate {


    in          KERNEL:NETWORK:35


    out         KERNEL:NETWORK:36
}
#define CPU 10
cpu {


    syscallrate KERNEL:CPU:10


    util
}
#define USER 20
#define SYSTEM 21
#define IDLE 22
cpu.util {


    user        KERNEL:CPU:USER


    sys         KERNEL:CPU:SYSTEM


    idle        KERNEL:CPU:IDLE
}

SEE ALSO¶

PCPIntro(1), pmcd(1), pmcpp(1), PCPIntro(3), PMAPI(3), pmErrStr(3), pmGetConfig(3), pmLoadASCIINameSpace(3), pmLoadNameSpace(3), pcp.conf(5) and pcp.env(5).