Shared resource allocation in multithreaded microprocessors.

Abstract

An approach is provided for allocating shared resources to threads in a multithreaded microprocessor based on the availability of the shared resource to each thread. The availability of the shared resource to a thread is determined based on the number of entries in the shared resource allocated to the thread and the number of active entries the thread has in the shared resource. Threads with low parallelism that are allocated a large number of entries in the shared resource and have a small number of active entries in the shared resource can operate efficiently with fewer entries in the shared resource and reduce the allocation limit in the shared resource.

Description

[Background technology]

[0001] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived and pursued. Thus, unless otherwise noted, it should not be assumed that any approach described in this section qualifies as prior art merely by virtue of its inclusion in this section. Moreover, it should not be assumed that any approach described in this section is well-understood, conventional, or conventional merely by virtue of its inclusion in this section.

[0002] Multithreaded microprocessors often have shared resources, such as load queues and reservation stations, that are used by multiple threads. The shared resources are often assigned to threads on a first come, first served basis. The problem with this approach is that if the threads using the shared resource have different execution characteristics, one thread may obtain an excessive share of the shared resource, thereby preventing other threads from executing efficiently. For example, one thread may obtain most of the entries in the load queue. In this case, the performance of other threads may be degraded if other threads could benefit from having many entries in the load queue, but there are too few entries available to those threads.

[0003] One technical solution to this problem is to limit the use of a shared resource by a thread. For example, the number of entries in a shared resource assigned to a thread can be capped across all threads or on an individual thread basis. However, because thread execution characteristics can vary significantly and some threads may benefit from having more than the limited number of entries in the shared resource, limiting the number of entries assigned to a thread without understanding the impact on a particular thread can degrade overall performance. Thus, a better approach to managing the use of shared resources in a multithreaded microprocessor is needed.

[0004] Embodiments are illustrated by way of example, and not by way of limitation, in the accompanying figures in which like references refer to similar elements and in which: [Brief description of the drawings]

[0005] [Figure 1] FIG. 1 is a block diagram illustrating a multi-threaded microprocessor. [Diagram 2] FIG. 2 is a block diagram representing tables of information used by shared resource logic to manage access to a shared resource. [Diagram 3] FIG. 2 is a block diagram illustrating a timeline on which shared resource logic operates to change the allocation of shared resources to threads. [Figure 4] 1 is a flow chart illustrating allocation of shared resources to threads on a multi-threaded microprocessor based on the availability of the shared resources to the threads. [Figure 5A] FIG. 2 depicts example usage data obtained for a thread over a first clock cycle window. [Figure 5B] FIG. 13 depicts example usage data obtained for a thread over a second clock cycle window. [Figure 5C]FIG. 13 depicts example usage data obtained for threads over a third clock cycle window. [Figure 5D] FIG. 13 depicts example usage data obtained for a thread over a fourth clock cycle window. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments. However, it will be apparent to those skilled in the art that the embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the embodiments. I. Overview II. Architecture III. Managing Thread Access to Shared Resources Based on Availability A. Overview B. Changing the shared resource allocation limits for a thread C. Usefulness Metrics D. Dealing with resource allocation fluctuations

[0007] (I. Overview) An approach is provided for allocating shared resources to threads in a multi-threaded microprocessor based on the utility of the shared resource to each thread. The utility of the shared resource to a thread is determined based on the number of entries in the shared resource allocated to the thread and the number of active entries the thread has in the shared resource. A thread that is allocated a large number of entries in the shared resource and has a small number of active entries in the shared resource indicates a low degree of parallelism and can operate efficiently with fewer entries in the shared resource, and can reduce allocations in the shared resource. As used herein, the term "active entries" refers to entries in the shared resource that are performing work (e.g., currently being used to prepare or execute an instruction). Different threads may have different levels of utility for the same shared resource, and the approach is applicable to any number of threads and shared resources. This approach can reduce the likelihood that one thread will acquire a large number of entries in the shared resource, thereby degrading the performance of other threads that use the shared resource.

[0008] (II. Architecture) 1 is a block diagram illustrating a multi-threaded microprocessor 100 including a control unit 110, an arithmetic logic unit (ALU) 120, thread registers 130, shared resources 140, and shared resource logic 150. Thread registers 130 are registers dedicated to a particular thread. A microprocessor can support any number of threads, although embodiments are not limited to a particular number of threads. Shared resources 140 may be any type of resource used by multiple threads in multi-threaded microprocessor 100. Examples of shared resources 140 include, but are not limited to, load queues, register files, reservation stations, etc.

[0009] Shared resource logic 150 manages the allocation of shared resources 140 to threads executing on multithreaded microprocessor 100 based on the availability of shared resources 140 to the threads, as described in more detail below. Shared resource logic 150 may be implemented by computer hardware, computer software, or any combination of computer hardware and software. Although shared resource logic 150 is depicted in FIG. 1 as a separate element for purposes of illustration, shared resource logic 150 may be incorporated into other elements (e.g., resource allocation logic, thread switching logic, and dispatch discipline logic) within multithreaded microprocessor 100. Multithreaded microprocessor 100 may include additional elements not depicted in FIG. 1, but which may vary depending on the particular embodiment.

[0010] III. Managing Thread Access to Shared Resources Based on Availability (A. Overview) The shared resource logic 150 evaluates the usefulness of the shared resource 140 to a thread and modifies the allocation limit assigned to the thread for the shared resource 140 based on the usefulness. As used herein, the term "allocation limit" is a limit on the number of entries in the shared resource 140 that can be assigned to a thread. FIG. 2 is a block diagram representing a table 200 of information used by the shared resource logic 150 to manage access to the shared resource 140. Each row in the table 200 corresponds to a thread executing on the multithreaded microprocessor 100. The columns of data for each thread include, in a first column, data identifying the thread, in a second column, the number of entries in the shared resource 140 currently assigned to the thread, in a third column, the number of active entries for the thread in the shared resource 140, and in a fourth column, a usefulness metric. The usefulness metric is the ratio of the number of active entries to the number of entries currently assigned to the thread. The information in the table 200 may be maintained internal or external to the multithreaded microprocessor 100. The number of entries in shared resource 140 allocated to each thread and the number of active entries in shared resource 140 per thread may be tracked using, for example, counters or other hardware elements.

[0011] FIG. 3 is a block diagram illustrating a timeline 300 in which shared resource logic 150 modifies a thread's assigned allocation limit for shared resource 140 based on the availability of shared resource 140 to the thread. Timeline 300 includes N number of time periods in the form of clock cycle windows (CCWs), each CCW being a set of clock cycles. The number of clock cycles in each CCW may be determined using performance modeling and may vary depending on the particular embodiment. Performance modeling may balance factors such as reacting quickly enough to prevent a thread from consuming too many entries in the shared resource and slowing down the performance of other threads, while not overly limiting the number of entries in the shared resource available to a thread. In an embodiment, each of the CCWs includes 16 clock cycles. The number of clock cycles may be configured in shared resource logic 150 or may be selectable via an operating system, for example. Although the CCWs are represented in FIG. 3 as being contiguous, the CCWs are not limited to being contiguous and may have interstitial clock cycles. Also, the number of interstitial cycles between CCWs may vary between CCWs and may vary over time. Although embodiments are described herein in the context of time periods in the form of clock cycle windows, embodiments are not limited to clock cycle windows per se.

[0012] Beginning at time T0, the threads' use of shared resource 140 is monitored over CCW1, and at time T1, the end of CCW1, the threads' use of shared resource 140 is evaluated and the allocation limits assigned to the threads are updated for the next CCW2. Note that CCW2 may occur any number of clock cycles after CCW1, and the number of interstitial clock cycles between CCW1 and CCW2 may vary over time. According to an embodiment, shared resource logic 150 identifies threads that have been assigned a large number of entries in the shared resource sufficient to potentially degrade the performance of other threads. Shared resource logic 150 then determines whether any of these threads have a small number of active entries in shared resource 150. Threads that have been assigned a large number of entries in shared resource 140 and have a small number of active entries in shared resource 140 have their allocation limits reduced because they can operate efficiently with fewer entries in shared resource 150.

[0013] According to an embodiment, the above-mentioned determination is made using thresholds (e.g., an allocation threshold and an active entry threshold). For a particular thread, if the number of entries in the shared resource currently allocated to the particular thread is above the allocation threshold and the number of active entries in the shared resource for the particular thread is below the active entry threshold, the allocation limit for the particular thread is reduced.

[0014] The allocation threshold may be designed using performance modeling and is selected to identify threads that are consuming a very large number of entries in the shared resource, i.e., potentially degrading the performance of other threads by monopolizing the shared resource. The active entry threshold is selected to identify threads that have low parallelism and therefore are likely to operate efficiently with a small number of entries in the shared resource, such as when a thread is executing a series of additional instructions, each of which depends on the result of the previous instruction. These two thresholds can be used in combination to prevent threads that have at least the threshold number of entries in the shared resource and have low parallelism from consuming many entries in the shared resource and degrading the performance of other threads.

[0015] (B. Changing shared resource allocation limits for threads) FIG. 4 is a flow chart 400 that depicts allocating shared resources to threads on a multi-threaded microprocessor based on the availability of the shared resources to the threads.

[0016] In step 402, initial allocation limits for a shared resource are established for threads on a multi-threaded microprocessor. In the present example, initial allocation limits for shared resource 140 are established for threads T0-T3 executing on multi-threaded microprocessor 100.

[0017] According to an embodiment, the initial allocation limit is the total number of entries available in the shared resource. For example, assuming shared resource 140 is a load queue with 50 entries, an initial allocation limit of 50 is established for each of threads T0-T3. Note that assigning the total number of available entries in shared resource 140 as the initial allocation limit for all threads could potentially allow any thread to consume a large number of entries in shared resource 140 and degrade the performance of other threads. Alternatively, the initial allocation limit may be less than the total number of entries available in the shared resource. For example, for a load queue with 50 entries, an initial allocation limit of 10 may be established for each of threads T0-T3.

[0018] The initial allocation limits may be thread specific. For example, a high priority thread (e.g., a thread having a special design or involved in meeting a particular quality of service (QOS) requirement) may be assigned a larger initial allocation limit than other threads having a lower priority. In the previous example, the high priority thread may be assigned an initial allocation limit of 50, and the other threads may be assigned an initial allocation limit of 30. The initial allocation limits may be preconfigured in shared resource logic 150, stored in configuration data used by shared resource logic 150, or configured via the operating system. Shared resource logic 150 may also reset the thread allocation limits to the initial allocation limits, for example, at power up or in response to receiving a command, such as an operating system command.

[0019] In step 404, the number of allocated entries and the number of active entries per thread are determined over a first set of clock cycles. For example, the shared resource logic 150 may determine the number of allocated entries and the number of active entries for threads T0-T3 across CCW1. FIG. 5A represents exemplary usage data for threads T0-T3 across CCW1. In this example, the initial allocation limit is 50 for threads T0-T3 across CCW1. The number of active entries is the number of entries currently doing work and may change during CCW1 as instructions are processed. Thus, according to an embodiment, the number of active entries is the minimum number of active entries during CCW1. In the example represented in FIG. 5A, thread T1 has the maximum number of active entries during CCW1, indicating the highest level of parallelism relative to the other threads, and thread T0 has the minimum number of active entries during CCW1. Correspondingly, thread T1 benefits more than thread T0 from having more entries in the shared resource 140.

[0020] In step 406, a first / next thread is selected. In this embodiment, thread T0 is selected, but any approach may be used to select the first thread to be evaluated. In step 408, a determination is made as to whether the number of entries allocated to the selected thread exceeds an allocation threshold. For example, shared resource logic 150 determines whether the number of entries in shared resource 140 allocated to thread T0 is greater than the allocation threshold. Assuming the allocation threshold is 10, 12 entries allocated to thread T0 is greater than the allocation threshold of 10, so the allocation threshold is met and control passes to step 410. This means that thread T0 has been allocated a large number of entries in shared resource 140, enough to potentially degrade the performance of other threads.

[0021] At step 410, a determination is made as to whether the number of active entries for the thread is less than the active entry threshold. As described above, the active entry threshold is used to identify threads that have a low degree of parallelism and therefore are more likely to operate efficiently with a smaller allocation of the shared resource. In this embodiment, the shared resource logic 150 determines whether the number of active entries for thread T0 in the shared resource 140 is less than the active entry threshold. Assuming that the active entry threshold is three, one active entry for thread T0 is less than the active entry threshold of three, so the active entry threshold is satisfied and control passes to step 412. By satisfying both the thresholds at steps 408 and 410, thread T0 has a large number of entries in the shared resource 140 sufficient to potentially degrade the performance of other threads and has a low degree of parallelism. Thus, thread T0 can operate efficiently with a small number of entries in the shared resource 140.

[0022] In step 412, the thread's allocation limit for the shared resource is reduced to prevent the thread from degrading the performance of other threads. In this example, the allocation limit for thread T0 for shared resource 140 is reduced during the next time period, i.e., the next clock cycle window CCW2. The amount of reduction to the allocation limit may vary depending on the particular embodiment, and the embodiment is not limited to any particular reduction method. According to the embodiment, the thread's allocation limit is reduced to a reduced allocation limit. For example, the entries allocated to thread T0 in shared resource 140 may be reduced from 50 to 10. The reduced allocation limit may be configured in shared resource logic 150 and / or may be selectable via the operating system. The value of the reduced allocation limit may be determined using modeling and is a value that is low enough to prevent the thread from degrading the performance of other threads.

[0023] Instead of reducing a thread's allocation limit for a shared resource to a reduced allocation limit, the thread's allocation limit may be reduced in stages. For example, the number of entries allocated to thread T0 may be reduced by one from 50 to 49, or by 10 from 50 to 40. More complex methods may be implemented for additional computational cost. For example, the reduction may be based on the level of active entries relative to the active entry threshold. In this example, a number of active entries that is 50% of the active entry threshold results in a 50% reduction in the number of entries allocated to the thread. According to an embodiment, the thread's allocation limit is reduced based on a utility metric for that thread.

[0024] According to an embodiment, reducing a thread's allocation limit does not cause the thread to immediately relinquish the entry. Rather, the thread relinquishes the entry as normal when it completes its work, but the thread is not granted additional entries in shared resource 140 until the thread's current number of allocated entries falls below the reduced allocation limit. In the previous example, thread T0 is not granted additional entries in shared resource 140 until the number of entries in shared resource 140 allocated to thread T0 falls below 10.

[0025] If, in step 408, the number of entries allocated to the thread is less than or equal to the allocation threshold, or if, in step 410, the number of active entries for the thread is greater than or equal to the active entry threshold, control proceeds to step 414 where the allocation limit for the thread is reset, i.e., increased. In other words, if a thread has a small number of entries in shared resource 140 allocated to it, the thread does not pose a threat to degrade the performance of other threads. Alternatively, if a thread has a large number of active entries and is highly parallel, the thread may benefit from having more entries in shared resource 140 and its allocation limit is not reduced. According to an embodiment, when the allocation limit for a thread is reset, the allocation limit for the thread is changed to the initial allocation limit. Alternatively, the allocation limit for the thread may be increased (increased) by a certain amount (e.g., an increase of one, or a larger increase, such as 5 or 10). This increase may be configured in shared resource logic 150 or may be selectable, for example, via the operating system. The allocation limit for a thread may also be increased based on a utility metric for the thread.

[0026] After the thread allocation limit has been reduced in step 412 or reset (increased) in step 414, a determination is made in step 416 whether more threads need to be processed. If so, control returns to step 406 where the next thread is selected and processed in the same manner. Once all of the threads have been processed, processing is complete in step 418. This process may be repeated any number of times for any number of threads.

[0027] According to an embodiment, the above test is performed after every clock cycle, and if step 414 is reached, the thread's allocation limit is reset to the initial allocation limit for the next CCW, and the thread is no longer tested during the current CCW. If step 414 is not reached for a particular thread during the current CCW, the thread's allocation limit remains reduced for the current CCW and the next CCW. Other examples include using the average number of allocated and active entries over a CCW, or using the number of allocated and active entries at the end of a CCW.

[0028] Using both the allocation threshold and the active entry threshold to identify threads for which the allocation limit should be reduced addresses the technical problem of how to prevent threads with low parallelism in a multi-threaded microprocessor from degrading the performance of other threads using a shared resource. This technical solution identifies threads that currently have at least a threshold number of entries in the shared resource allocated, as represented by the allocation threshold, such that the thread is potentially "monopolizing" the shared resource and limiting the number of entries in the shared resource available to other threads. Then, based on the active entry threshold, a determination is made as to whether the identified thread has very few active entries in the shared resource, i.e., entries that are doing work. The allocation limit for this thread is reduced because a small number of active entries indicates low parallelism and that the thread can continue to operate efficiently even with a small number of entries in the shared resource. Conversely, threads with few allocated entries or a large number of active entries do not have their allocation limit reduced.

[0029] Over time, the execution characteristics of a thread may change, for example, due to different instructions. Thus, the number of entries in a shared resource allocated to a thread, and the number of active entries for that thread, may also change over time. Thus, threads that did not initially have their allocation limits reduced may have their allocation limits reduced after a later CCW.

[0030] Continuing with the previous example, Figure 5B depicts exemplary usage data obtained for threads T0-T3 across CCW2. The quota limit for thread T0 is 10 after a downward adjustment made after CCW1. The quota limits for threads T1-T3 have been reset to the initial quota limit of 50 because all of the numbers of allocated entries for those threads are below the quota threshold.

[0031] At time T2, after CCW2, the above test is performed again, and thread T0, although its number of active entries has increased slightly from 1 to 2, satisfies both the allocation threshold (allocated entries>10) and the active entry threshold (active entries<3), so the allocation limit for thread T0 remains at 10. However, thread T2 also satisfies both thresholds, since its 12 allocated entries are more than the allocation threshold of 10 and its 2 active entries are less than the active entry threshold of 3. Thus, the allocation limit for thread T2 is reduced to 10 for the next set of clock cycles, i.e., CCW3. The allocation limits for both threads T1 and T3 are reset to the initial allocation limit of 50, since their corresponding numbers of allocated entries are less than the allocation thresholds.

[0032] FIG. 5C represents exemplary usage data obtained for threads T0-T3 over CCW3 at time T3. During CCW3, the allocation limit for threads T0 and T2 is still 10 because of the downward adjustments made after CCW1 for thread T0 and after CCW2 for thread T2. In CCW3, the number of allocated entries for thread T0 remains above the allocation threshold, but the number of active entries for thread T0 has increased from 2 to 5. Thus, the allocation limit for thread T0 is reset (increased) to the initial allocation limit of 50 for CCW4. During CCW3, thread T2's 12 allocated entries continue to exceed the allocation threshold, and thread T2 has only one active entry, which is below the active entry threshold of 3. Thus, thread T2 continues with a reduced allocation limit of 10 in CCW4. The allocation limit for thread T1 is reset to an initial allocation limit of 50 because seven active entries have exceeded the active entry threshold of three, while eleven allocated entries for thread T1 exceed the allocation threshold of ten. The allocation limit for thread T3 is reset to an initial allocation limit of 50 because six allocated entries are below the allocation threshold of ten. Thus, while thread T1 is using a greater number of entries in shared resource 140, thread T1 has a level of parallelism greater than the active entry threshold, and therefore its allocation limit is not reduced.

[0033] FIG. 5D represents exemplary usage data obtained for threads T0-T3 over CCW4 at time T4. The number of allocated entries for thread T0 decreases from 11 to 8 over CCW4 as thread T0 completes work and entries in shared resource 140 are freed. At the end of CCW4, the allocation limit for thread T0 is reset to the initial allocation limit of 50 because the number of allocated entries for thread T0 is below the allocation threshold. The number of allocated entries for thread T1 continues to grow over CCW4, but the allocation limit for thread T1 is again reset to the initial allocation limit because the number of active entries exceeds the active entry threshold. The number of allocated entries for thread T2 decreases from 12 to 10 over CCW4 as thread T2 completes work and entries in shared resource 140 are freed. At the end of CCW4, the allocation limit for thread T2 remains reduced to 10 because the number of allocated entries for thread T2 is still greater than the allocated threshold of 10 and the number of active entries is less than the active entry threshold. Over CCW4, the number of allocated entries for thread T3 increases from 6 to 10, but the allocation limit for thread T2 is reset to the initial allocation limit of 50 because the number of active entries exceeds the active entry threshold. Thus, while both threads T1 and T3 have the potential to monopolize shared resource 140, they both have a number of active entries that exceeds the active entry threshold, indicating a high level of parallelism. Thus, their allocation limits are reset to the initial allocation limit.

[0034] (C. Usefulness Metrics) As previously described herein, the usefulness metric is a thread-specific ratio of the number of active entries to the number of entries currently assigned to the thread. The usefulness metric may be calculated every N clock cycles or every clock cycle over a period of cycles. For example, the usefulness metric may be calculated as the average usefulness metric over N clock cycles.

[0035] The utility metric may be used as an alternative to the allocation threshold and active entry threshold to determine whether the allocation limit for a thread should be changed. For example, instead of steps 408 and 410 in FIG. 4, the utility metric may be calculated for a selected thread and compared to the utility threshold to determine whether the allocation limit for the thread should be changed. This test may be performed every clock cycle, every N clock cycles, or over a period of cycles, and individual utility metric values ​​may be tested, or an average of N utility metric values ​​may be tested against the utility threshold. According to an embodiment, a windowed approach may be used in which the utility metric of a thread must show low usage (e.g., does not meet the utility threshold) over each clock cycle of the clock cycle window before the thread's allocation limit is reduced. Alternatively, the average utility metric of the thread over the clock cycle window may be compared to the utility threshold.

[0036] The utility metric may be used to determine a new allocation limit for a thread. According to an embodiment, when it is determined that an allocation for a thread is to be changed, instead of using the allocation threshold and either the active entry threshold or the utility threshold to reduce the allocation to a reduced allocation limit as described herein above in step 412 of FIG. 4, the utility metric for the thread is used to determine a new allocation limit for the thread. The utility metric may be used as an input to a formula implemented by the shared resource logic 150, the output of which is the new allocation limit for the thread. Depending on the particular formula used, it may be possible to gradually increase the allocation limit for a thread as the number of active entries for the thread increases, indicating increased parallelism even in cases where the thread may have fewer entries than the active entry threshold number of active threads. Using the utility metric to calculate a new allocation limit for a thread may provide more flexibility than using a reduced allocation level as described above, but it is more computationally intensive and may result in division by zero problems.

[0037] D. Dealing with resource allocation fluctuations The level of parallelism of a thread may vary significantly over successive CCWs as the type of instructions for the thread changes. Using the approach described herein, the number of entries in shared resource 150 allocated to a thread may vary between the total number of entries in the shared resource (e.g., 50) and a reduced allocation level (e.g., 10).

[0038] Techniques are provided for reducing variability in resource allocation to threads by increasing the number of clock cycles that a thread must demonstrate a satisfactory level of utility before the thread's allocation of the shared resource is increased. According to an embodiment, a larger CCW is used to increase a resource allocation to a thread than to decrease the resource allocation to the thread. For example, a CCW of 16 clock cycles may be used to decrease the resource allocation to a thread, and 32 CCWs or more clock cycles are used to increase the resource allocation to a thread. Thus, the number of entries in the shared resource 150 allocated to a particular thread may be reduced after a set of 16 clock cycles, but the particular thread must demonstrate a sufficiently high level of parallelism for a longer period, i.e., 32 clock cycles, for the number of entries in the shared resource to be increased. Alternatively, instead of using a larger window of clock cycles to increase the shared resource allocation, multiple windows of clock cycles may be used to increase the shared resource allocation. For example, a CCW of 16 clock cycles may be used to decrease the resource allocation to a thread, and two or more CCWs of 16 clock cycles are used to increase the resource allocation to a thread.

[0039] According to another embodiment, different thresholds are used to increase the resource allocation. For example, when considering whether to increase the number of entries in the shared resource 140 allocated to a thread, an allocation threshold of 5 and an active entry threshold of 4 may be used in each of steps 408 and 410 of FIG. 4. In this example, the lower allocation threshold of 5 is easier to meet compared to the allocation threshold of 10 that would be used if the thread's allocation is not currently reduced. Similarly, the higher active entry threshold of 4 is more difficult to meet compared to the active entry threshold of 3 that would be used if the thread's allocation is not currently reduced. Thus, the combination of a lower allocation threshold and a higher active entry threshold increases the likelihood that a thread with a reduced allocation of the shared resource will continue to have a reduced allocation of the shared resource.

[0040] Although embodiments are described herein in the context of a multithreaded microprocessor having a single shared resource, the embodiments are not limited to this example and are applicable to any number of shared resources, including multithreaded microprocessors having shared resource logic managing multiple shared resources, and multithreaded microprocessors having multiple shared resource logic managing multiple shared resources.

Claims

1. 1. A multi-threaded microprocessor, comprising: a shared resource having a plurality of entries; a shared resource logic; The shared resource logic includes: a number of entries allocated to any one of a plurality of threads during a first period from the plurality of entries in the shared resource; and a number of active entries in the shared resource for the thread during the first period; and and determining using the number of entries allocated to the thread during the first period and the number of active entries in the shared resource for the thread during the first period to modify an allocation limit that is an upper limit on the number of entries allocated to the thread for the shared resource for a second period; [0023] Multithreaded microprocessor.

2. modifying a quota limit, which is an upper limit on the number of entries assigned to the thread for the shared resource for the second time period, comprises decreasing the quota limit assigned to the thread for the shared resource for the second time period.

2. The multithreaded microprocessor of claim 1.

3. a quota limit, which is an upper limit on the number of entries that may be assigned to the thread for the shared resource for the second time period, is increased by the quota limit increment amount or decreased to a reduced quota limit.

3. The multithreaded microprocessor of claim 2.

4. the shared resource logic is configured to reduce an allocation limit, an upper limit on the number of entries that may be allocated to the thread for the shared resource for the second time period, in response to determining both that the number of the entries allocated to the thread during the first time period is greater than a first threshold and that the number of active entries in the shared resource for the thread during the first time period is less than a second threshold.

2. The multithreaded microprocessor of claim 1.

5. The shared resource logic includes: determining a utility metric for the thread, the utility metric being a ratio of the number of active entries in the shared resource for the thread to the number of entries allocated to the thread; comparing the utility metric for the thread to a utility threshold to determine whether to modify the allocation limit for the thread; [0023] 2. The multithreaded microprocessor of claim 1.

6. The shared resource logic includes: determining and comparing the utility metric for the thread to the utility threshold for each clock cycle of a clock cycle window; reducing the allocation limit for the thread in response to the utility metric for the thread not satisfying the utility threshold for each clock cycle of the clock cycle window; [0023] 6. The multithreaded microprocessor of claim 5.

7. the shared resource logic is configured to modify the allocation limit for the thread based on the utility metric for the thread.

6. The multithreaded microprocessor of claim 5.

8. Increasing an allocation limit assigned to the thread for the shared resource for the second time period includes increasing an upper limit on the number of entries assigned to the thread for the shared resource for the second time period to a total number of available entries in the shared resource.

2. The multithreaded microprocessor of claim 1.

9. The shared resource logic includes: in response to determining that the number of the entries allocated to the thread during the first time period is less than or equal to a first threshold, or that the number of the active entries in the shared resource for the thread during the first time period is greater than or equal to a second threshold, increasing an allocation limit that is an upper limit on the number of entries that may be allocated to the thread for the shared resource for the second time period.

2. The multithreaded microprocessor of claim 1.

10. the first threshold value and the second threshold value are selected based on a number of the entries in the shared resource allocated for a period of the thread.

10. The multithreaded microprocessor of claim 9.

11. The shared resource logic includes: and increasing an allocation limit, which is an upper limit on the number of entries that may be allocated to the thread for the shared resource, in response to determining that the number of the entries allocated to the thread during the multiple time periods is equal to or less than a first threshold, or that the number of the active entries in the shared resource for the thread during the multiple time periods is equal to or greater than a second threshold.

2. The multithreaded microprocessor of claim 1.

12. the number of active entries in the shared resource for the thread during the first period of time is a minimum number of active entries in the shared resource for the thread during the first period of time.

2. The multithreaded microprocessor of claim 1.

13. the shared resource being one or more of a load queue, a register file, or a reservation station; 2. The multithreaded microprocessor of claim 1.

Images