JP2003521029A - Dynamic priority external transaction system - Google Patents

Abstract

(57) Summary Multi-mode transaction queues can operate according to a default priority scheme. This transaction queue may use a second priority scheme when a congestion event is detected.

Description

Detailed Description of the Invention

BACKGROUND As is well known, many modern computing systems employ a multi-agent architecture. A typical system is shown in FIG. In this system, a plurality of agents 110 to 160 communicate with each other via an external bus 170 according to a predetermined bus protocol. "Agent"
May include general purpose processors 110-140, memory controller 150, interface chipset 160, input / output devices and / or other integrated circuits (not shown) that handle data requests. Bus 170 allows multiple external bus transactions to proceed concurrently.

An agent (eg, 110) typically includes a transaction management system that receives requests from other components of the agent and handles external bus transactions that satisfy the requests. The bus sequencing unit 200 ("BSU") shown in Figure 2 is an example of such a transaction management system. BSU 200 includes arbiter 210, internal cache 220, internal transaction queue 230, external transaction queue 240, external bus controller 250, prefetch queue 260, and the like. BSU 200 manages transactions on external bus 170, eg, in response to a data request issued by an agent core (not shown in FIG. 2).

Arbiter 210 can receive data requests from various other sources, such as prefetch queue 260, as well as data requests from the core. The arbiter 210 may make a selection among the data requests that the arbiter 210 may receive at the same time and output one to the rest of the BSU 200.

The internal cache 220 can store data in several cache entries. It may have logic that, in response to a data request, determines whether cache 220 is storing a valid copy of the requested data. As used herein, "data" refers to instruction data and various data that can be used by an agent. Internal cache 2
20 can provide the requested data in response to the data request.

The internal transaction queue 230 can also receive data requests issued by the arbiter 210 and store them. In the case of a read request, coordination with internal cache 220 is made to determine whether the requested data "hits" (can be served by) internal cache 220. If not, that is, if the data request "disengages" the internal cache 220, the internal transaction queue 230 transfers the data request to the external transaction queue 240.

External transaction queue 240 interprets data requests and creates external bus transactions to fulfill the requests. The external transaction queue 240 may be occupied by several queue registers. It manages the agent's transaction as it proceeds on the external bus 170. For example, if data is available for a transaction, the external transaction queue 240 retrieves the data and forwards it to the requester (eg, core) in the agent.

Prefetch queue 260 can identify a predetermined pattern in a read request issued by a core (not shown). For example, the memory locations (addresses A, A + 1, A + 2,
A + 3 ,. ． ． ), The prefetch queue 260 may issue a prefetch request to read data from the next address (A + 4) in the sequence before the core actually requests the data. it can. By anticipating a request for data, the prefetch queue 260 can ensure that it is available in the internal cache 220 when the core issues a request for that data. The data will be provided to the core from the internal cache 220 rather than from external memory. This is a much faster operation. Here, this type of prefetch request will be referred to as "patterned prefetch".

The BSU 200 may also implement a second type of prefetch, called “blind prefetch”. When the core issues a read request for data at a certain address (denoted as address B), which is executed by an external bus transaction, the blind prefetch mechanism transfers the data at the second memory address (B + 1) to A second foreign bus transaction can be retrieved. Blind prefetch can cause a pair of external bus transactions for every read request from the core that cannot be executed internally. Blind prefetching can improve processor performance by performing twice the number of cache lines (or cache sectors) required to fulfill a core read request. Also in this case, when the core finally requests the data from the data prefetched from the other address (B + 1), the data is stored in the internal cache 220 at the time when the core issues a read request for the data. Will exist. Blind prefetch requests may also be generated from patterned prefetch requests. Using the example above, the address A + 4
The patterned prefetch request for A can be extended to address A + 5 by blind prefetch.

Returning to FIG. 1, particularly in a multiprocessor computer system,
It is well known that external bus 170 can limit system performance. The external bus 170 is often operating at a clock speed much slower than the agent's internal clock speed. The core often issues some requests for data within the time that the external bus 170 can complete a single external bus transaction. That is, a single agent can consume more bandwidth than one external bus 170. If multiple agents must share the external bus 170, each agent will be allocated only a portion of the bandwidth available on the bus 170. In multi-agent systems, it is often the case that agents have to wait idle while the external bus is searching for the data it needs to move forward.

External transaction queue 240 (FIG. 2) may include control logic that prioritizes pending requests for posting on the external bus. In general, the core read is set as a priority order than the prefetch read, and the prefetch read is set as a priority order than the write. The core read request identifies the data that the core needs immediately. The prefetch read request identifies data that the core may need at any time in the future. The write request identifies the data the agent is about to return to the system's storage. Therefore, the external transaction queue 24
The 0 may contain control logic that posts requests on the external bus according to this priority.

Pre-determined priority schemes have inherent drawbacks. Request is,
It is typically stored in the external transaction queue 240 until it is completed on the external bus. During periods of high congestion when the external transaction queue 240 is fully or nearly full, prefetch requests as well as write requests may prevent new core requests from being stored in the queue 240. A low priority request will remain stored in the queue until the external bus transaction for that request completes. That is, a lower priority request may prevent a higher priority request from being fulfilled. This will limit the performance of the system.

Therefore, there is a need in this field for a congestion management system for external transaction queues within agents. Also in this area,
What is needed is a system that maintains a first priority scheme when there is no system congestion, but provides a dynamic priority system that implements a second priority when a congestion event occurs. .

SUMMARY Embodiments of the present invention provide a multi-mode transaction queue for one agent. Transaction queues can operate according to a default priority scheme. This transaction queue can use a second priority scheme if a congestion event is detected.

DETAILED DESCRIPTION Embodiments of the present invention provide a transaction queue that provides a well-balanced response to congestion events. This transaction queue selectively invalidates pending transactions in the queue. That is, it selectively invalidates transactions that are not currently posted on the external bus. In one embodiment, the transaction queue first invalidates the blind prefetch request. The transaction queue can also invalidate unposted prefetch requests that are stored with the associated posted prefetch request. Finally, in cases of extreme congestion, such as when there is no space available for new requests, patterned prefetch requests where the transaction queue is not posted can be overridden.

These embodiments provide a transaction queue with a dynamic priority scheme. When not congested, the transaction queue operates according to the first priority scheme. For example, the transaction queue is
As described above, the priority of the core read request can be set on the prefetch request, and the priority of the prefetch request can be set on the write request. However, the transaction queue may employ a second priority scheme when a congestion event occurs. For example, the transaction queue may maintain the core read request as the highest priority request while re-prioritizing the write request as the next highest priority request. The transaction queue can also invalidate prefetch requests stored in the transaction queue.

FIG. 3 illustrates an external transaction of an agent according to an embodiment of the present invention.
FIG. 3 is a block diagram of a queue 300. The external transaction queue 300 includes a controller 310 and a plurality of queue registers 320-1 to 320-N (collectively applying the label 320). Within each queue register are a plurality of fields, including an address field 330, a first status field 340 and a second status field 350.

The external transaction queue 300 is suitable for use within agents that perform blind prefetch. Status field 340,
Each 350 stores information about each external bus transaction that will be executed according to the blind prefetch pair.
The address field 330 contains the base to which the transaction is directed.
Addresses can be stored. Usually, there is a predetermined relationship between the address field 330 and the status fields 340,350. For example, address D is address field 33 of register 320-1.
When stored at 0, status field 340 maintains status information for the transaction destined for address D and status field 350 maintains status information for the second transaction destined for address D + 1. The form of doing is possible.

The status fields 340, 350 can store management information related to each transaction. This type of information includes the type of request, information about the status of each transaction on the external bus (that is, whether it has already been posted, in what transaction phase the request is, whether the transaction is complete, etc.). Information may be included regarding the destination of the data that will be received according to the transaction. Generally, when status fields 340 and 350 together indicate that their corresponding transactions have completed, the transactions are registered.
Cleared from.

According to one embodiment of the present invention, the status fields 340, 350 respectively indicate whether the corresponding transaction was generated according to a core request (“C”) or according to a prefetch request (“P”). It may include a sub-field that identifies whether or not it has been done. In FIG. 3, seven requirements are core requirements,
It indicates that the rest are prefetch requests. In this example, registers 320-1, 320-4, 320-5, 320-6, 320-8, 320-11.
, And 320-N are storing transactions initiated by core requests. The status field 340 or 35 of one of these registers
0 identifies the transaction as originating from a core request; the other status field indicates a blind prefetch request.

The remaining registers 320-2, 320-3, 320-7, 320-9, and 3
20-10 identifies the patterned prefetch request extended by blind prefetch. These status fields 340, 350
Indicates that the corresponding request is a prefetch request.

Controller 310 interfaces external transaction queue 300 with another element within the agent (see, eg, FIG. 2).
The controller 310 registers the transaction in or deletes it from the queue register 320, and in the address field 330 and
Data can be written to the fields 340 and 350. The controller 310 can also schedule the order of transactions posted on the external bus 170 (FIG. 1). In one embodiment, the controller 3
10 can be a state machine.

According to one embodiment of the present invention, controller 310 may selectively disable prefetch requests during a congestion event in BSU 200. In the first embodiment, when the transaction queue 300 is congested, the transaction queue can disable blind prefetch transactions that have not yet been posted on the external bus. This can be accomplished, for example, by marking the status field of the blind prefetch transaction as complete, even if the transaction has not yet been posted. In this embodiment, the transaction can be flushed from the external transaction queue 300 when the core read request is completed on the external bus.

In another embodiment, when the transaction queue is congested,
The transaction queue 300 can evict any patterned prefetch requests stored in the queue but not yet posted on the external bus. The external transaction queue 300 may evict an unstarted prefetch request by simply deallocating the associated queue register.

In yet another embodiment, the external transaction queue 300 is when the transaction queue is congested and the transaction queue 300 is storing a patterned prefetch transaction that has already started. Can disable unposted prefetch transactions in a prefetch pair. Now consider the patterned prefetch request illustrated in register 320-2 of FIG. As can be seen, the status field 350 indicates that the first prefetch transaction is pending, but not yet posted on the external bus. In contrast, the status field 340 indicates that the second prefetch transaction was posted on the external bus. In this embodiment, the transaction queue 300 may mark the first transaction as complete in response to a congestion event. The second prefetch request in this case is allowed to continue until completed. Upon completion, transaction queue 300 may deallocate register 320-2 because both status fields 340 and 350 identify completed transactions.

FIG. 4 illustrates a transaction queue 300 (FIG. 3) according to an embodiment of the invention.
6 is a flowchart of a method 1000 performed by. In response to the congestion event, the transaction queue may determine whether a new request has entered the transaction queue (step 1010). In response to receipt of the new request, the transaction queue may determine if the register is available for the new request (step 1020). If possible, store the request in an available register (step 1030).
The request store can be performed according to conventional methods in the art.
The transaction queue 300 can determine the base address of the request and enter the appropriate information in various fields 330-350 of the allocated register.

If no registers were available in step 1020, transaction queue 300 may deallocate the registers associated with the unposted pair of patterned prefetch requests (step). 1040). In performing this step, the transaction queue 300 deallocates the patterned prefetch request, the status fields 340, 350 of which together indicate that the respective transaction has not yet been posted to the external bus. You can If there are no registers 320 identifying a pair of prefetch requests that have not been started, the newly received request is stopped (this step not shown).
This request is prevented from entering the transaction queue.

As a result of step 1030, or if there was no request received in step 1010, the transaction queue determines whether it is operating in congestion mode (step 1050). If not, transaction queue 300 ends this iteration of method 1000.

If the transaction queue 300 is operating in the congestion mode, the transaction queue determines whether it is storing a pending blind prefetch transaction (step 1060).
). If so, transaction queue 300 may disable one of the blind prefetch transactions (step 1070). Step 1070 can be applied to blind prefetches associated with core requests or patterned prefetch requests. If not, or as a result of step 1070, the method ends.

The method 1000 preferably provides a well-balanced response to congestion. First
In response, the transaction queue invalidates the blind prefetch request from the transaction queue. As described above, the prefetch request is placed under the core request as a class. Experience has also shown that it is appropriate to place blind prefetches below patterned prefetches. Patterned prefetch is likely to be more efficient than blind prefetch. The patterned prefetch is issued in response to the established pattern of core reads from memory. Blind prefetch is not tied to any measurable feature. Therefore, patterned prefetch is likely to retrieve the data that the core will eventually request, and one should choose to disable blind prefetch, leaving it alone.

When blind prefetch is disabled, the rate at which register 320 is available for newly received requests increases. As previously indicated, blind prefetch is associated with core read requests. The core read request is the highest priority request handled by the transaction queue. These are posted on the external bus with the highest priority.

If the congestion persists after disabling all blind prefetches, then the transaction queue is pending, at the second level of priority, associated with the in-progress prefetch request. The patterned prefetch request may be overridden (step 1080). Since one of the prefetch requests has already been posted to the external bus, it is expected to finish within a predetermined time. However, even if it does, the state of the second pending prefetch request (ie, the request invalidated in step 1080) prevents the associated register from being deallocated. . Step 1080 ensures that the registers are deallocated at the end of the posted prefetch request by marking the pending prefetch request as complete.

At the third level of priority, the transaction queue deallocates the register storing the pair of pending prefetch requests for newly received requests. This is done only if there are no registers for the newly received request.

The principle of the present invention is to allow several different trigger events to cause the transaction queue 300 to determine that it is operating in a congestion mode. In the first embodiment, the transaction queue 300 determines that it is congested based on the number of allocated or unallocated registers 320 in the queue. For example, 90% of registers or 100
If the transaction queue determines that the% is full, then it can determine that it is operating in congestion mode.

In a second example, the transaction queue may determine the occurrence of a congestion event based on the measured external bus latency. As we all know,
Usually agents operate according to a predetermined bus protocol. The bus protocol tells when a new request can be posted on the external bus, and to any of the many possible agents, for each request "slot", ie for each posting of the new request on the bus. With respect to opportunity, rules can be set to govern whether posting of new requests is allowed on the bus. In such an embodiment, transaction queue 300 may measure the number of request slots that transaction queue 300 will pass through before gaining ownership of the bus. If the measured number of slots exceeds a predetermined threshold, the transaction queue 300 can determine that a congestion event is occurring.

According to another embodiment, the transaction queue 300 may change its response to a congestion event depending on the type of congestion detected. As an example, consider the case where a transaction queue is able to detect two types of triggering events mentioned above: (1) when the number of available registers is below a certain threshold (ie, Transaction queue is completely full), and (2) the measured latency on the external bus exceeds the threshold value. According to one embodiment, if the transaction queue 300 is completely full, the transaction queue 30
A 0 will invalidate all prefetch requests, but if the measured latency on the external bus exceeds the threshold, then only the blind prefetch request need be invalidated. This embodiment may be advantageous as it provides a simple implementation and provides a clear distinction between high and low congestion events in terms of severity.

The above discussion distinguishes between pending and posted requests. Here, a posted request is a request already initiated on the external bus. External buses are typically defined by a predetermined bus protocol, which specifies the gradual phase through which a transaction passes toward completion. The congestion management methods described in the above embodiments do not interfere with already posted transactions. A pending request, on the other hand, is a request stored in the BSU bus but not yet initiated on the external bus. The congestion management method of the present invention can invalidate pending requests according to the techniques described in the above embodiments.

As previously indicated, embodiments of the present invention provide a transaction queue 300 that can operate according to a dynamic priority scheme. The first priority scheme can be defined for a transaction queue in a congestion free state. However, the transaction queue may implement a second priority scheme when congestion is detected. In the above embodiment, the transaction queue invalidates the prefetch request.

The congestion management techniques described in the above embodiments are directed to read requests processed by the transaction management system. As is well known, the BSU may handle other types of requests, such as write requests that are not intended to read data in the agent. The congestion management techniques described in the above embodiments are not intended to interfere with how the transaction management system handles these other types of requests.

Several embodiments of the present invention have been shown and described in detail herein. It will be appreciated, however, that modifications and variations of the present invention are covered by the above teachings and are within the scope of the appended claims without departing from the spirit and intended scope of the invention. .

[Brief description of drawings]

[Figure 1]   FIG. 3 is a block diagram of a multi-agent computer system.

FIG. 2 is a block diagram illustrating an agent's bus sequencing unit.

FIG. 3 is a block diagram of an agent's external transaction queue in accordance with one embodiment of the present invention.

[Figure 4]   6 is a flowchart of a congestion management method according to an embodiment of the present invention.

─────────────────────────────────────────────────── ─── Continued front page    (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE, TR), OA (BF , BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, G M, KE, LS, MW, MZ, SD, SL, SZ, TZ , UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, C A, CH, CN, CR, CU, CZ, DE, DK, DM , DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, K E, KG, KP, KR, KZ, LC, LK, LR, LS , LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, PL, PT, RO, R U, SD, SE, SG, SI, SK, SL, TJ, TM , TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW (72) Inventor Pludhobi, Chinaby             USA ・ 97229 ・ Oregon ・ Po             Orlando Northwest Diafi             Field Drive 17924 (72) Inventor Marl, Deborah Tee             U.S.A. 97210 Oregon PO             Zealand Northwest Petitgle             Grove Street 2564 F term (reference) 5B061 BB04 BB06 BC02 PP04

Claims (26)

[Claims] 1. A transaction queue for an agent operating according to a dynamic priority scheme, operating according to a default priority scheme, and using a second priority scheme when a congestion event is detected. Transaction queue. 2. A management method for an external transaction within an agent: queuing data of a plurality of read requests; for each queued request, a blind associated with each request. Storing prefetch transaction data; disabling selected stored prefetch requests when a transaction congestion event occurs; 3. The management method according to claim 1, wherein the transaction congestion event occurs when the number of queued requests exceeds a predetermined threshold. 4. The management method according to claim 1, wherein the transaction congestion event occurs when a queue storing queued requests is full. 5. The management method according to claim 1, wherein the transaction congestion event occurs when a measured latency of a posted transaction exceeds a predetermined threshold. 6. A management method for external transactions within an agent, the method comprising: queuing data for a plurality of external bus transactions; at least one queue being associated with each transaction with respect to the performed transaction. A method of storing data of a blind prefetch transaction; a step of disabling the blind prefetch transaction when a transaction congestion event occurs. 7. The management method according to claim 6, wherein the transaction congestion event occurs when the number of queued requests exceeds a predetermined threshold. 8. The management method according to claim 6, wherein the transaction congestion event occurs when a queue for storing queued requests is full. 9. The management method according to claim 6, wherein the transaction congestion event occurs when a measured latency of a posted transaction exceeds a predetermined threshold. 10. A method of management within an agent for external transactions comprising: a plurality of read requests, a particular read request associated with execution being performed by an agent core, data being prefetched. Queuing data for another particular read request of interest; disabling the prefetch request when a transaction congestion event occurs; 11. The management method of claim 10, wherein the transaction congestion event occurs when the number of queued requests exceeds a predetermined threshold. 12. The management method of claim 10, wherein the transaction congestion event occurs when a queue that stores queued requests is full. 13. The management method according to claim 10, wherein the transaction congestion event occurs when a measured latency of a posted transaction exceeds a predetermined threshold. 14. A multi-mode management method within an agent for external transactions: queuing data for multiple core read requests; for each core read request, associated with each core read request. Stored data of a blind prefetch transaction; queuing data of a prefetch request related to a pattern of core read requests; Disable step; Disable the prefetch request when a transaction congestion event occurs in the second mode. 15. The management method according to claim 14, wherein the transaction congestion event occurs when the number of queued requests exceeds a predetermined threshold. 16. The management method of claim 14, wherein the transaction congestion event occurs when a queue that stores queued requests is full. 17. The management method according to claim 14, wherein the transaction congestion event occurs when a measured latency of a posted transaction exceeds a predetermined threshold. 18. A transaction queue comprising: a controller; a plurality of queue registers, each queue register having an address field and a status field associated with a pair of transactions associated with an address. A transaction queue in which the controller modifies one of the status fields in the register to invalidate each transaction in response to a congestion event. 19. The transaction queue stores a core read request, a blind prefetch request, and a patterned prefetch request, and the invalidating transaction is a blind prefetch request. The transaction queue according to claim 18. 20. The transaction queue of claim 19, wherein the controller invalidates a patterned prefetch request if there is no valid blind prefetch request. 21. An agent bus sequencing unit, comprising: an arbiter; an internal cache coupled to the arbiter; a transaction storing data for an external transaction to be executed by the agent, coupled to the arbiter. A transaction queue, wherein the transaction is selected from the group of core read requests, blind prefetch requests, and patterned prefetch requests; and an external bus controller coupled to the transaction queue A bus sequence in which the transaction queue invalidates a selected transaction in response to a congestion event in the bus sequencing unit. Nshingu unit. 22. The bus sequencing unit of claim 21, wherein the selected transaction is a blind prefetch request. 23. The bus of claim 21, wherein the selected transaction is a patterned prefetch request if there is no valid blind prefetch request in the transaction queue.
Sequencing unit. 24. Congestion on an external transaction, wherein the external transaction is stored in a transaction queue as a pair taken from a set of core read request and blind prefetch request pairs and patterned prefetch request pairs. In the management method: receiving a new request in a transaction queue; determining whether the transaction queue has space to store the new request, and if not patterning from the transaction queue Redissolving the pair of prefetch requests made and storing the new request in the transaction queue. 25. The congestion management method according to claim 24, further comprising the step of invalidating the blind prefetch request. 26. The method further comprising invalidating the first patterned prefetch request when the second patterned prefetch request in the pair is posted. The congestion management method according to claim 23.