FIG. 1A shows a conventional processor 100 including a plurality of cores 1050, 1051, . . . , 105N. Each of the cores 105 may include an advanced programmable interrupt controller (APIC) timer 110, a plurality of performance monitor counters 115, an instruction based sampling (IBS) fetch control register 120, and an IBS operation (Op) control register 125, which are examples of system-wide performance monitoring resources that may be simultaneously required by many software applications.
FIG. 1B shows a conventional system including the processor 100, a plurality of drivers 1351 and 1352, a user interface 140 and a plurality of users 1451 and 1452. Referring to FIGS. 1A and 1B, a user 145 may make a time-based profile (TBP) request requiring use of an APIC timer 110, an event-based profile request requiring use of a performance monitor counter 115, or an IBS-based profile request requiring use of either an IBS fetch control register 120 or an IBS operation control register 125. However, the performance monitoring resources in each of the cores 105 of the processor 100 may not be shared by more than one user 145 at a time. Instead, once any of these performance monitoring resources are accessed by a first user, all other users are denied access to these same resources. For example, an arbitration protocol, such as one defined by Microsoft, may use a particular performance monitoring resource in the processor 100. If a first user 1451 follows the arbitration protocol, a second user 1452 will be denied access to the particular performance monitoring resource. However, if the second user does not follow the arbitration protocol, multiple accesses to the same performance monitoring resource may cause a system crash or malfunction of performance monitoring.
The performance monitor counters 115 in the processor 100 of FIG. 1A may be used by system software to count specific performance events associated with an operation, (e.g., retired instructions). A performance counter may be incremented in order to track the number of events that occur, (e.g., used for a sampling profile), as well as generate an interrupt when a predetermined threshold is reached, (i.e., the counter overflows). IBS is a code profiling mechanism that enables the processor 100 to select a random instruction fetch or micro-Op associated with an operation after a predetermined threshold, (e.g., number of cycles, instruction fetch count, instruction micro-Op dispatch count), has been reached, record specific performance information about the operation and generate an interrupt when the operation is completed. An interrupt handler in a driver 135 shown in FIG. 1B may then read the performance information that was logged for the operation. Instruction fetch sampling provides information about instruction translation look-aside buffer (TLB) and instruction cache behavior. The data collected for instruction fetch performance is different from the data collected for instruction execution performance.
Event counter multiplexing is a well-known technique used in hardware performance profiling. The event multiplexing technique allows one user to use many hardware events on a limited number of performance counters in a timeshared manner. However, by itself, event counter multiplexing does not support simultaneous performance monitoring resource usage by many other users.
Another well-known technique is to use a performance monitoring unit (PMU) arbitration library for resource management. However, a PMU arbitration library does not resolve conflicts to shared performance monitoring resources. For example, if a performance resource is accessed by a user, other requests to use the same performance monitoring resource are rejected.
Since the number of available performance resources in the processor 100 is limited, the applications that need to access these resources end up competing for the limited resources. Competing needs by these applications may cause a conflict when attempting to share performance monitoring resources. Thus, a management mechanism is needed to reduce conflicts associated with sharing performance monitoring resources to avoid a system crash or malfunction of performance monitoring.