AMD Athlon™, AMD Athlon™64, and AMD Opteron™ processors have four performance event counters. Prior to CodeAnalyst 2.6, event sampling was limited to a maximum of four different hardware event types per sampling session. Only four events could be measured per run. A minimum of two runs was needed to collect all data for five or more events. Event counter multiplexing removes the need for running multiple sessions when data for five or more events are needed.
Events can be separated into event groups. Each group identifies events to be collected with a maximum of four events per group. Event groups are defined in an event-based profile configuration using the Edit Event Configuration dialog box. In CodeAnalyst Linux 2.8, event multiplexing is accomplished by re-programming the performance counters when a timer interrups is generated by the driver. The interval between each timer can be specified in the Edit Event Configuration dialog box.
Certain factors must be taken into consideration when designing event groups.
If a particular event is measured in more than one group, the event should be configured with the same event count (sampling period) in all groups. This assures that all samples for that event have the same statistical weight.
The run time for any session sampling should be long enough to build a statistically accurate data profile of program behavior.
In the Edit Event Configuration dialog box, select the predefined profile configuration Assess performance.
This profile configuration uses event counter multiplexing to measure two groups (A and B) of four events.
Select | Performance Event |
Group
|
0x76 | CPU clocks not halted* |
A
|
0xc0 | Retired instructions* |
A
|
0xc2 | Retired branch instructions |
A
|
0xc3 | Retired mispredicted branch instructions |
A
|
0x40 | Data Cache accesses* |
B
|
0x41 | Data cache misses |
B
|
0x46 | L1 and L2 DTLB miss |
B
|
0x47 | Misaligned accesses |
B
|
Note: * Indicates a high frequency event.
|
When data collection is started with this event configuration, CodeAnalyst samples events in Group A for the duration specified and then samples events in Group B for the durations specified. This process repeats and continues until the sampling session ends according to the run control criteria set in the Session Settings dialog box.
Ensure run time is long enough to build up a statistically accurate picture of program behavior. Lengthening the duration of the data collection period may be necessary to increase the number of samples taken.
Two additional suggestions should be considered when designing event groups: