Resource management subsystem that maintains fairness and order

• US 9,836,325 B2
• Filed: 05/21/2012
• Issued: 12/05/2017
• Est. Priority Date: 05/21/2012
• Status: Active Grant

• Current Assignee: NVIDIA Corporation
• Original Assignee: NVIDIA Corporation
• Inventors: Fetterman, Michael, Gadre, Shirish, Edmondson, John H., Paranjape, Omkar, Rajendran, Anjana, Hill, Eric Lyell, Selvanesan, Rajeshwaran, McCarver, Charles, Mitchell, Kevin, Heinrich, Steven James
• Primary Examiner(s): Kim, Sisley
• Application Number:
  US13/476,791
• Publication Number:
  US 20130311999A1
• Time in Patent Office: 2,024 Days
• Field of Search: None
• CPC Class Codes: G06F 2209/507 Low-level
• CPC Class Codes: G06F 9/5011 the resources being hardware resources other than CPUs, Servers and Terminals

Abstract

One embodiment of the present disclosure sets forth an effective way to maintain fairness and order in the scheduling of common resource access requests related to replay operations. Specifically, a streaming multiprocessor (SM) includes a total order queue (TOQ) configured to schedule the access requests over one or more execution cycles. Access requests are allowed to make forward progress when needed common resources have been allocated to the request. Where multiple access requests require the same common resource, priority is given to the older access request. Access requests may be placed in a sleep state pending availability of certain common resources. Deadlock may be avoided by allowing an older access request to steal resources from a younger resource request. One advantage of the disclosed technique is that older common resource access requests are not repeatedly blocked from making forward progress by newer access requests.

Claims

1. A method for managing requests for common resources in a processing pipeline, the method comprising:

receiving a first request, from a process executing on a first processor, for a first common resource;

receiving a second request for a second common resource;

determining that the first common resource and the second common resource are not available for allocation;

in response, delaying servicing the first request and the second request;

causing a first entry associated with the first request to be created in replay buffer, wherein the first entry in the replay buffer includes at least one program instruction for performing one or more replay operations that execute the first request;

subsequent to delaying servicing the first request, receiving a third request for the first common resource;

subsequent to receiving the third request, determining the first common resource has become available for allocation;

making the first common resource available to the first request, prior to making the first common resource available to the third request;

determining that one or more sleeping access requests are waiting for the second common resource;

as a result, identifying the second common resource as a scarce resource;

determining that the second common resource is now available for allocation;

waking up a single access request included in the one or more sleeping access requests; and

making the second common resource available to the single access request.

2. The method of claim 1, wherein the first entry includes a field to track the age of the first request, wherein the first entry indicates that the first request is associated with at least the first common resource.

3. The method of claim 2, further comprising, upon receiving the third request, searching the replay buffer for any entry corresponding to a request that is associated with the first common resource.

4. The method of claim 3, further comprising identifying via the first entry that the first request is associated with the first common resource, and, in response, determining that the first request should be serviced prior to the third request.

5. The method of claim 2, further comprising creating a second entry in the replay buffer for the second request to track the age of the third request, wherein the second entry indicates that the third request is associated with at least the first common resource.

6. The method of claim 5, upon determining that the first common resource is available, searching the replay buffer for any entry corresponding to a request that is associated with the first common resource.

7. The method of claim 5, further comprising identifying via the first entry and the second entry that the first request and the third request are associated with the first common resource and that the first request is older than the third request, and, in response, determining that the first request should be serviced prior to the third request.

8. The method of claim 2, wherein the first entry further includes information that indicates the status of the first common resource.

9. The method of claim 8, wherein the status of the first common resource is that the first common resource is needed by the first request but not allocated to the first request or that the first common resource is locked and unavailable to the first request.

10. The method of claim 1, further comprising:

subsequent to waking up the single access request, determining that no sleeping access requests are currently waiting for the second common resource;

as a result, identifying the second common resource as no longer a scarce resource;

determining that the second common resource is again available for allocation; and

waking up all sleeping access requests via a broadcast wakeup call.

11. The method of claim 1, wherein the first entry further comprises at least one of one or more parameters for the one or more replay operations, and contents of one or more registers for the one or more replay operations.

12. The method of claim 1, further comprising, after determining that the first common resource has become available for allocation:

retrieving the first entry from the replay buffer; and

executing the at least one program instruction in order to perform the one or more replay operations that execute the first request.

13. A subsystem for managing requests for common resources, the subsystem comprising:

a processor configured to implement a processing pipeline; and

a total order queue (TOQ) coupled to the processing pipeline that performs the steps of;

receiving a first request for a first common resource;

receiving a second request for a second common resource;

determining that the first common resource and the second common resource are not available for allocation;

in response, delaying servicing the first request and the second request;

causing a first entry associated with the first request to be created in a replay buffer, wherein the first entry in the replay buffer includes at least one program instruction for performing one or more replay operations that execute the first request;

subsequent to delaying servicing the first request, receiving a third request for the first common resource;

subsequent to receiving the third request, determining that the first common resource has become available for allocation;

making the first common resource available to the first request, prior to making the first common resource available to the third request;

determining that one or more sleeping access requests are waiting for the second common resource;

as a result, identifying the second common resource as a scarce resource;

determining that the second common resource is now available for allocation;

waking up a single access request included in the one or more sleeping access requests; and

making the second common resource available to the single access request.

14. The subsystem of claim 13, wherein the first entry includes a field to track the age of the first request, wherein the first entry indicates that the first request is associated with at least the first common resource.

15. The subsystem of claim 14, wherein the TOQ further performs the step of, upon receiving the third request, searching the replay buffer for any entry corresponding to a request that is associated with the first common resource.

16. The subsystem of claim 15, wherein the TOQ further performs the steps of identifying via the first entry that the first request is associated with the first common resource, and, in response, determining that the first request should be serviced prior to the third request.

17. The subsystem of claim 14, wherein the TOQ further performs the step of creating a second entry in the replay buffer for the third request to track the age of the third request, wherein the second entry indicates that the third request is associated with at least the first common resource.

18. The subsystem of claim 17, wherein the TOQ further performs the step of, upon determining that the first common resource is available, searching the replay buffer for any entry corresponding to a request that is associated with the first common resource.

19. The subsystem of claim 17, wherein the TOQ further performs the steps of identifying via the first entry and the second entry that the first request and the third request are associated with the first common resource and that the first request is older than the third request, and, in response, determining that the first request should be serviced prior to the third request.

20. The subsystem of claim 14, wherein the first entry further includes information that indicates the status of the first common resource, and the status of the first common resource is that the first common resource is needed by the first request but not allocated to the first request or that the first common resource is locked and unavailable to the first request.

21. A computing device, comprising:

a processor; and

a total order queue (TOQ) that is coupled to the processor to perform the steps of;

receiving a first request for a first common resource;

receiving a second request for a second common resource;

determining that the first common resource and the second common resource are not available for allocation;

in response, delaying servicing the first request and the second request;

causing a first entry associated with the first request to be created in a replay buffer, wherein the first entry in the replay buffer includes at least one program instruction for performing one or more replay operations that execute the first request;

subsequent to delaying servicing the first request, receiving a third request for the first common resource;

subsequent to receiving the third request, determining that the first common resource has become available for allocation;

making the first common resource available to the first request, prior to making the first common resource available to the third request;

determining that one or more sleeping access requests are waiting for the second common resource;

as a result, identifying the second common resource as a scarce resource;

determining that the second common resource is now available for allocation;

waking up a single access request included in the one or more sleeping access requests; and

making the second common resource available to the single access request.