Abstract:
A method and apparatus are provided for efficiently managing hot spots in a resource managed computer system. The system utilizes a controller, a series of requestor groups, and a series of loan registers. The controller is configured to allocate and is configured to reallocate resources among the requestor groups to efficiently manage the computer system. The loan registers account for reallocated resources such that intended preallocation of use of shared resources is closely maintained. Hence, the computer system is able to operate efficiently while preventing any single requestor or group of requestors from monopolizing shared resources.

Description:
CROSS-REFERENCED APPLICATIONS 
   This application relates to co-pending U.S. patent applications Ser. No. 10/738,720 entitled “METHOD OF RESOURCE ALLOCATION USING AN ACCESS CONTROL MECHANISM”, filed concurrently herewith. 
   BACKGROUND OF THE INVENTION 
   1. Technical Field 
   The present invention relates generally to resource management within a computing system, and more particularly, to reallocating unused resources according to both usage and fairness while maintaining the desired usage presets determined by a preallocation algorithm. 
   2. Description of the Related Art 
   Within a given computer architecture, such as a Broadband Engine, there exists a finite number of resources, such as memory or I/O, that are available for use. These resources are commonly referred to as shared resources. Typically, though, there is not a single desired use nor single user. Instead, there are usually multiple users competing for shared resources. These requests should be managed in such a way as to improve the use of the architecture construct, so as to have the most rapid response and limit the wasting of resources. 
   Moreover, there is a significant problem of starvation, where a user can be prevented from utilizing a given system or resource. Essentially, other users occupy the full bandwidth of a network or system. Typically, the system&#39;s or network&#39;s available bandwidth is allocated between the users wherein rules for allocation are set defining bandwidth limits depending on the class of user. Simple techniques, such as time multiplexing for applications or users and priority arbitration, have been utilized. 
   However, even time multiplexing and priority arbitration schemes lack controls and guarantees needed for real-time applications and usage. Essentially, applications or users can easily overrun a system or network leading to retries, long lag times, and overall poor performance. Some of the problems as a result of applications or users overrunning a system or networks are bottlenecks and denial of service. Schemes, which attempt to prevent the denial of service, usually result in wasting of resources, though. 
   However, once the computer system has begun operation, the allocation is not as simple as a percentage allocation. In fact, the varying users can be one of the two extremes for usage: sparse or high rate. If a user is a sparse user, the resource allocated to a sparse user can go unused. Hence, the available shared resources would be wasted. If a user is a high rate user, other competing user could be backlogged with pending requests for the shared resource. To alleviate the problem of backlogged requests and dead time on resources, algorithms, known as fairness algorithms, have been developed to reallocate the unused time on the shared resources to other requesters with pending requests. 
   A problem with according fairness is that it can skew the intended target allocation. High rate users can in fact steal bandwidth from more sparse users. By stealing the bandwidth, the preallocation percentages of use can be rendered virtually meaningless. The reason is that, thus far, there has not been an algorithm in place to reset the usage to the preallocation levels. 
   Therefore, there is a need for a method and/or apparatus for controlling the usage of resources that addresses at least some of the problems associated with conventional methods and apparatuses for controlling resources. 
   SUMMARY OF THE INVENTION 
   The present invention provides an apparatus, method, and computer program for managing tokens for usage of a shared resource in a computer system. There is at least comprise a plurality of shared resources coupled to the bus. Also, there is at least comprise a plurality of requester groups coupled to the bus. Each requester of the plurality of requestor groups at least has the ability to request the usage of at least a shared resource of a plurality of shared resources. A control module is also coupled to the bus. The control module is configured to allocate and is configured to reallocate tokens for usage of a shared resource. Also, a plurality of arbitration modules are coupled to the control module. At least one arbitration module of the plurality of arbitration modules is associated with at least one requestor group of the plurality of requester groups. A plurality of memory cells are coupled to the control module that account for reallocated tokens. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     For a more complete understanding of the present invention, and its advantages, references will now be made in the following Detailed Description to the accompanying drawings, in which: 
       FIG. 1  depicts a block diagram of a system structure incorporating a token manager; 
       FIG. 2  depicts a block diagram illustrating a Token Manager to alleviate the problems of hot spots; 
       FIG. 3  depicts a flow chart that depicts token granting and loan registration for a requesting user group and a given shared resource at the time of a new request; and 
       FIG. 4  depicts a flow chart that depicts token granting and loan registration for a regenerating user group and a given shared resource at the time of token generation. 
   

   DETAILED DESCRIPTION OF THE INVENTION 
   In the following discussion, numerous specific details are set forth to provide a thorough understanding of the present invention. However, those skilled in the art will appreciate that the present invention can be practiced without such specific details. In other instances, well-known elements have been illustrated in schematic or block diagram form in order not to obscure the present invention in unnecessary detail. Additionally, for the most part, details concerning network communications, electromagnetic signaling techniques, and the like, have been omitted inasmuch as such details are not considered necessary to obtain a complete understanding of the present invention, and are considered to be within the understanding of persons of ordinary skill in the relevant art. 
   It is further noted that, unless indicated otherwise, all functions described herein can be performed in either hardware or software, or some combination thereof. In a preferred embodiment, however, the functions are performed by hardware, such as a computer or an electronic data processor, in accordance with code, such as computer program code, software, and/or integrated circuits that are coded to perform such functions, unless indicated otherwise. 
   Referring to  FIG. 1  of the drawings, the reference numeral  100  generally designates a block diagram illustrating a system structure that utilizes a Token Manager to alleviate the problems of denial of service and bottlenecks. Denials of service, delays, and bottlenecks are as a result of requesters, such as a Direct Memory Access (DMA) unit, or groups of requestors blocking other requesters from accessing a given resource. For example, a DMA unit occupying an Input/Output (IO) device and not allowing any other processor from utilizing the IO device is a denial of service. 
   The requesters, which could be a cache or DMA Controller, are labeled R 0   2 , R 1   3 , R 2   4 , and Input/Output Controller (IOC)  10  for four given requestors. These labeled requesters are devices that request usage of managed resources, such as IO devices, and unmanaged resources, such as Synchronous Dynamic Random Access Memory (SDRAM). There may be one or more requesters of varying types. For example, an IO controller  10  acts as a requester and a managed resource, whereas R 0   2  is a requestor only. 
   Each of the requesters is further connected through a communication channel to the local bus  1 . R 0   2  is connected to the local bus  1  through a first communication channel  14  and a second communication channel  15 . R 1   3  is connected to the local bus  1  through a third communication channel  18  and a fourth communication channel  19 . R 2   4  is connected to the local bus  1  through a fifth communication channel  20  and a sixth communication channel  21 . IOC is connected to the local bus  1  through a seventh communication channel  26  and an eighth communication channel  27 . Each requester will have at least one or more communication channels connected to a given local bus that operate in a variety of manners. Moreover, any of the aforementioned communications channels would encompass wireless links, optical links, conductor cable links, packet switched channels, direct communication channels and any combination thereof. 
   The unmanaged resources are labeled UMR 0   5  and UMR 1   6  for two given unmanaged resources. There can be one or more unmanaged resources of a variety of types. An unmanaged resource is typically a resource that cannot be totally used by a single or small group of requesters and typically can not bottleneck. 
   Each of the unmanaged resources is further connected through a communication channel to the local bus  1 . UMR 0   5  is connected to the local bus  1  through a ninth communication channel  24  and a tenth communication channel  25 . UMR 1   6  is connected to the local bus  1  through an eleventh communication channel  30  and a twelfth communication channel  31 . Each unmanaged resource will have at least one or more communication channels connected to a given local bus that operate in a variety of manners. Moreover, any of the aforementioned communications channels would encompass wireless links, optical links, conductor cable links, packet switched channels, direct communication channels and any combination thereof. 
   Typically, resources that relate to critical bottlenecks are managed. There can be one or more managed resources. The managed resources illustrated are the memory controller (Mem Cntl)  8 , the managed resource (MR)  9 , the IO controller (IOC)  10 , and the IO devices  11 . The managed resources are examples and illustrations of resources that can be used by multiple requesters at the same time. The immediate disclosure should not be read as limiting the number or type of managed resources. 
   There are a variety of interfaces between the managed resources and the local bus  1 . The Mem Cntl  8  is connected to the local bus  1  through thirteenth communication channel  16  and a fourteenth communication channel  17 . MR  9  is connected to the local bus  1  through a fifteenth communication channel  22  and a sixteenth communication channel  23 . IOC  10  is connected to the local bus  1  through the seventh communication channel  26  and the eighth communication channel  27 . It should be noted that the IOC  10  is a unique mechanism that operates as both a requester and a managed resource. However, there can be a multitude of other mechanisms that possess similar properties to the IOC  10 . The use of a single IOC  10  is for the purposes of example and illustration and should not be read as limiting. Finally, IO devices  11  is connected to the IOC  10  through a sixteenth communication channel  28 , and through a seventeenth communication channel  29 . One should also note that the IO devices  11  are further under the control of the IOC  10 . Thus, the seventh communication channel  26  and the eighth communication channel  27  of the IOC  10  are shared by the IOC  10  and IO devices  11 . However, there are a multitude of other mechanisms that possess similar properties to the IO devices  11  and the IOC  10 . The use of IO devices  11  and the IOC  10  is for the purposes of example and illustration and should not be read as limiting. Also, each managed resource will have at least one or more communication channels connected to a given local bus that operate in a variety of manners. 
   Moreover, certain paths of usage between the requestors and the managed resources have special designations. These paths are designated as Management Paths (MP). Most paths are multitude of communication channels and the local bus  1  that interconnect the requesters to the managed resources. For example, the first communication channel  14 , the local bus  1 , and the fifteenth communication channel  22  comprise an MP between the R 0   2  and MR  9 . The significance of the MPs are that a token is used for a communication across the given MP. 
   A token manager  12  is used to solve the problems of denial of service and bottlenecks. For example, a denial of service is a requester occupying all of the bandwidth of a IO device, preventing any other requester from using the IO device. Each requester is assigned a Resource Allocation ID (RAID), which is typically related to its register. Requestors with the same RAID are referred to as a Resource Allocation Group (RAGs). The token manager  12  allocates the usage for each managed resource for a given RAG. The characteristics of the RAGs are determined by software, and could be dynamically changed. Essentially, each RAG is allocated a predetermined percentage of bandwidth by software, which is based on the desired system performance. In order for a requestor within a RAG to communicate with or utilize a given managed resource, a token is granted, by the token manager, to the requester that allows for the utilization of a managed resource. Without a token, there can be no utilization of a managed resource. 
   Regarding the tokens, the token manager  12  does not arbitrarily assign the tokens. The token manager  12 , instead, generates resource tokens for each RAG by virtue of a rate counter. Also, a given requester, though, cannot accumulate the tokens, and the sum of all rates for all of the RAGs must not exceed the capabilities of the resource. 
   However, in certain cases, such as IO devices  11 , multiple tokens are required for communication with a resource. For example, when an IO device  11  accesses memory (not shown), there is both an IO Controller (IOC)  11  and a Memory Controller (Mem Cntl)  8  required to complete the transfer. Hence, for such a transfer, there is a requirement of two tokens, one for each Managed Resource (for example, the IO Controller and Memory Controller). Thus, tokens can be accumulated to complete a single task or communication in special cases wherein multiple tokens are required to perform a single task or communication, such as with IO devices  11 . 
   Once the token manager  12  has assigned the token to a RAG, then the requester belonging to the RAG can utilize the token and initiate the communication. A requester must first generate an internal token request, which includes both a RAID and Managed Resource, and is then forwarded to the Token Manager. Upon reception of the given request, the Token Manager will grant the requested token if and when a token is assigned to the RAG. When all needed tokens are granted, the requester is then allowed to perform the pending request. 
   However, there can be times when the given RAG does not have a requester with a pending request for the available managed resource. At these specified times, a token can be granted to a requestor in another RAG. The problem of “hot spots,” where two or more entities can try to access the same resource at about the same time, is generally alleviated by the use of a Token Manager  12 . However, there can be another problem in that a specific requester or RAG can occupy a substantial portion of the bandwidth by virtue of borrowing, where one RAG borrows a token from another RAG. Hence, there is a need to structure a Token Manager to avoid at least some of the problems. 
   Referring to  FIG. 2  of the drawings, the reference numeral  200  generally designates a block diagram illustrating a Token Manager to alleviate the problems of hot spots. The Token manager comprises a Contoller  210 , a plurality of round-robin pointers  220 ,  223 , and  225 , and a plurality of loan registers  230 ,  231 ,  232 ,  233 ,  234 ,  235 ,  236 ,  237 , and  238 . 
   Within the token manager  12  of  FIG. 1 , there are a variety of devices performing specific duties that allow the proper performance of the token manager  12  of  FIG. 1 . The controller  210  is configured to be the device for providing communication and control of each allocation between the varying loan registers  230 ,  231 ,  232 ,  233 ,  234 ,  235 ,  236 ,  237 , and  238  and round-robin selectors  220 ,  223 , and  225 . The controlling software assigns each requester to a RAG, assigns a RAID to each RAG, and controls resource allocation. Each RAG uses a round-robin pointer  220 ,  223 , and  225  to cycle through the targets wherein a new token is generated each time the countdown timer times out for each target to determine if there is a pending request for a given resource. 
   The first round robin pointer for a first RAG  220  is interconnected to the controller  210  though a first communication channel  221 . The second round robin pointer for a second RAG  223  is interconnected to the controller  210  though a second communication channel  224 . The third round robin pointer for a third RAG  225  is interconnected to the controller  210  though a third communication channel  226 . There can be multiple round robin pointers or a single round robin pointer, as depicted in  FIG. 2 , for each respective RAG. Moreover, there can be a single RAG or multiple RAGs, as depicted in  FIG. 2 . Also, each RAG will have at least one or more communication channels connected to a Controller  210  that operate in a variety of manners. Moreover, any of the aforementioned communications channels or MPs would encompass wireless links, optical links, conductor cable links, packet switched channels, direct communication channels and any combination thereof. 
   Associated with each RAG, there are a plurality of loan registers  230 ,  231 ,  232 ,  233 ,  234 ,  235 ,  236 ,  237 , and  238 . The use of loan registers  230 ,  231 ,  232 ,  233 ,  234 ,  235 ,  236 ,  237 , and  238  allow for the accurate and efficient management of shared resources by accounting for the tokens borrowed from another RAG. A first loan register  230  is associated to the first RAG that corresponds to a first shared resource and is interconnected to the Controller  210  through a fourth communication channel  240 . A second loan register  231  is associated to the first RAG that corresponds to a second shared resource and is interconnected to the Controller  210  through a fifth communication channel  241 . A third loan register  232  is associated to the first RAG that corresponds to a third shared resource and is interconnected to the Controller  210  through a sixth communication channel  242 . A fourth loan register  233  is associated to the second RAG that corresponds to the first shared resource and is interconnected to the Controller  210  through a seventh communication channel  243 . A fifth loan register  234  is associated to the second RAG that corresponds to the second shared resource and is interconnected to the Controller  210  through an eighth communication channel  244 . A sixth loan register  235  is associated to the second RAG that corresponds to the third shared resource and is interconnected to the Controller  210  through a ninth communication channel  245 . A seventh loan register  236  is associated to the third RAG that corresponds to the first shared resource and is interconnected to the Controller  210  through a tenth communication channel  246 . An eighth loan register  237  is associated to the third RAG that corresponds to the second shared resource and is interconnected to the Controller  210  through an eleventh communication channel  247 . A ninth loan register  238  is associated to the third RAG that corresponds to the third shared resource and is interconnected to the Controller  210  through a twelfth communication channel  248 . 
   There can be multiple loan registers or a single loan register, as depicted in  FIG. 2 , for each respective RAG. Moreover, there can be a single RAG or multiple RAGs, as depicted in  FIG. 2 . Also, each loan register will have at least one or more communication channels connected to a Controller  210  that operate in a variety of manners. There can be a single or multiple loan registers, as disclosed herein, to account for the loaning and borrowing of tokens among RAGs. Moreover, any of the aforementioned communications channels or MPs would encompass wireless links, optical links, conductor cable links, packet switched channels, direct communication channels and any combination thereof. 
   In order to grant a token assigned to one RAG from a different RAG, the token manager  12  of  FIG. 1  makes a determination of availability as illustrated in  FIGS. 3 and 4 . However, availability can become an issue at two strategic points: at the time of token generation and at the time of a new request.  FIG. 3  depicts token granting and loan registration upon a new request.  FIG. 4  depicts token granting and loan registration at the time of token generation. Also, it should be noted that the flow charts of  FIGS. 3 and 4  collectively describe the operation of a RAG, a round-robin selector, a loan register, and the controller, collectively. 
   Referring to  FIG. 3  of the drawings, the reference numeral  300  generally designates a flow chart that depicts token granting and loan registration for a requesting RAG and a given shared resource at the time of a new request. 
   In step  301 , when a requesting RAG has a new request, there is a determination of whether there is a token available for the given shared resource. If there is a token available, there must be a further determination if there is a token request pending from another RAG that had previously loaned a token to this RAG  302 . If there is not an outstanding loan for a token, then the available token is granted to the requesting RAG  306 . However, if there is an outstanding loan, then the token is granted to the loaning RAG  303 , repaying the loan. Also, upon repayment, the loan register is reset to reflect the repayment  304 , and the requesting RAG&#39;s request is marked as pending  305 . 
   In step  301 , when a requesting RAG has a new request and there is not a token available, another sequence must be employed. Firstly, there should be a determination if the requesting RAG has loaned a token for the given resource  307 . If a token has not been loaned, then the request is marked as pending  310 . However, if there has been a loaned token, then there should be a determination if there is a token available from a borrowing RAG  308 . If there is not a token available from a borrowing RAG, the request is marked as pending  310 . If there is a token available from a borrowing RAG, then a token is obtained from the borrowing RAG  309 , repaying the loan. Upon repayment the loan register is reset to reflect the repayment  311 . 
   Referring to  FIG. 4  of the drawings, the reference numeral  400  generally designates a flow chart that depicts token granting and loan registration for a regenerating RAG and a given shared resource at the time of a token generation. 
   In step  401 , when a regenerating RAG is regenerating a token, there is a determination of whether there is a previous token available for the given shared resource. If there is a previously generated token available, there should be a determination if a loaning RAG has a pending request for the same token  402 . However, if there is pending request elsewhere, then the token is granted to a RAG with a pending request  404 , and the loan register is set to reflect the loan to the RAG with a pending request  405 . 
   In the case where there is not a loaning RAG with a pending request for the same token, then another sequence should be employed. The previous token is discarded  403 . Then, there should be a determination whether the owning RAG has a pending request for the new token  407 . If there is a pending request, the new token is granted to the owning RAG  408 . If there is not another pending request, then the previously generated token is held over until regeneration  409 . 
   In step  401 , when regenerating RAG is regenerating a token and there is not a previously generated token available, another sequence must be employed. Firstly, there must be a determination if there is a pending request for a loaning RAG  406 . If there is not a pending request for a loaning RAG, Then, there should be a determination whether the owning RAG has a pending request for the new token  407 . If there is a pending request, the new token is granted to the owning RAG  408 . If there is not another pending request, then the previously generated token is held over until regeneration  409 . However, if there is a pending request for a loaning RAG, the token is granted to the loaning requestor  411 , repaying the loan. Upon repayment, the loan register is reset to reflect the repayment  412 . 
   Hence, the accounting methodology allows for the preservation of the target allocation set forth by the preallocation algorithm. By accounting for the reallocation or loaning of generated tokens and subsequent realignment, the target allocation is only temporarily disturbed. Also, resources are utilized to the maximum extent, so as to prevent waste. 
   It will be understood from the foregoing description that various modifications and changes can be made in the preferred embodiment of the present invention without departing from its true spirit. This description is intended for purposes of illustration only and should not be construed in a limiting sense. The scope of this invention should be limited only by the language of the following claims.