Abstract:
A method and apparatus are provided for efficiently managing limited resources is a given computer system. The system utilizes a token manager that assigns tokens to groups of associated requestors. The tokens are then utilized by the requesters to occupy the given resource. The allocation of these tokens, thus, prevents such problems as denial of service due to a lack of available resources.

Description:
CROSS-REFERENCED APPLICATIONS  
       [0001]     This application relates to co-pending U.S. patent applications entitled “TOKEN SWAPPING FOR HOT SPOT MANAGEMENT” (Docket No. AUS920030720US1), filed concurrently herewith. 
     
    
     BACKGROUND OF THE INVENTION  
       [0002]     1. Field of the Invention  
         [0003]     The present invention relates generally to management of resources within a computing system and, more particularly, managing access to a resource to provide a guaranteed availability while maintaining high utilization of the resources.  
         [0004]     2. Description of the Related Art  
         [0005]     Within a given computer architecture, such as a Broadband Engine or a large SMP system, there exists a finite number of resources, such as processors, memory, I/O devices and interconnect buses that are available for use. In the current art resource management systems such as operating systems, hypervisors or virtual machine layers allocate processors, memory and I/O devices to specific tasks for specific periods of time, typically using a time-sliced approach based on task priorities and resource requirements. However, these management systems do not actively manage the interconnect buses that connect and provide access to the resources. This lack of bus resource management can significantly limit the capability to provide a “guaranteed” utilization of a resource during a specific period of time due to delay of access, particularly where there are multiple processors, memory and I/O devices sharing common buses concurrently executing multiple tasks. For instance, in a case where there are two tasks concurrently running on two different processors, accessing two different banks of memory, one tasks completion time can be adversely affected by the bus utilization and access patterns of the second task, even though to the resource management facility, both tasks have dedicated processor and memory resources. Techniques such as dropping packets of information and retrying operations are typically used for management of over committed resources in networking applications. However, these techniques do not work in systems having time critical tasks because of the retry delays and inherent inefficiencies.  
         [0006]     Time slicing and partitioning of processors, I/O and memory with priority arbitration schemes lack access controls for the resources needed for real-time applications and usage when there are a plurality of these resources attached to shared buses. Essentially, applications or tasks can easily congest a bus or a memory leading to stalls, retires, long lag times, and overall poor performance even though the management system properly provided the processor, memory or I/O resource to the task. Some of the major problems as a result of applications or tasks overrunning a system are bottlenecks and denial of service. A scheme, which allocates the bus for a task at a specific time, typically provides very poor overall utilization of system resources thus introducing considerable inefficiency.  
         [0007]     Therefore, there is a need for a method and/or apparatus for controlling the usage and access to resources in a system executing concurrent tasks which addresses the problem of resource access using shared resources that addresses at least some of the problems associated with conventional methods and apparatuses for controlling usage and access to resources in a system executing concurrent tasks.  
       SUMMARY OF THE INVENTION  
       [0008]     The present invention provides for managing system resources. There are a plurality of managed resources and a plurality of requesters that at least request and at least utilize the managed resources with a pending request. Associated with the requesters are a plurality of resource allocation groups, wherein requestors are assigned to a group based on a resource usage characteristic. A local bus that at least allows for communication and data transfer between the plurality of requestors and the plurality of managed resources is also provided. There is also a token manager that at least controls the usage of the managed resources. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0009]     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:  
         [0010]      FIG. 1  is an illustration of unrestricted request of a resource;  
         [0011]      FIG. 2  is a block diagram of a system structure utilizing a token manager;  
         [0012]      FIG. 3  is a flow chart describing the token availability process; and  
         [0013]      FIG. 4  is an example of granting an unused token. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0014]     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.  
         [0015]     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.  
         [0016]     Moreover, it should be further noted that the method and apparatus described is based on operation at a system level. However, a similar device and/or methodology can be implemented at a network level through mechanisms such as Quality of Service.  
         [0017]     Referring to  FIG. 1  of the drawings, the reference numeral  100  generally designates an illustration of unrestricted request of a resource.  
         [0018]     Normally, with an unmanaged system as illustrated in the timing diagram in  FIG. 1 , there can be problems caused by the occupation of resources resulting in denial of service through stalls and retires as mentioned above. For the sake of simplicity and illustration,  FIG. 1  is an example of a 1-deep request queue, which is one requester, such as a Direct Memory Access (DMA) unit. At times  1  and  2 , there is only a single request for a resource with ample time and availability to process the request. However, at time  3 , a request is pending, but before the request can be processed, another request is queued at time  4 . Thus, the request at time  4  is stalled, or possibly retired, as illustrated as shaded. As a further example, while the request at time  4  is pending, a fifth request is queued at time  5 . This fifth request is also stalled, or possibly retired, as illustrated as shaded. These delays result in bottlenecks or denials of service.  
         [0019]     Referring to  FIG. 2  of the drawings, the reference numeral  200  generally designates a block diagram of a system structure utilizing a token manager.  
         [0020]      FIG. 2  is an illustration of a system structure  200  to alleviate the problems of denial of service and bottlenecks. Denials of service, delays, and bottlenecks are as a result of requestors, such as a Direct Memory Access (DMA) unit, or groups of requesters blocking other requesters from accessing a given resource. For example, a DMA unit occupying an IO device and not allowing any other processor to utilize the IO device is a denial of service. In  FIG. 2 , there are multiple requestors and multiple resources that each interact through a connection with a local bus  1 .  
         [0021]     The requestors are labeled R 0   2 , R 1   3 , R 2   4 , and IOC (I/O Controller)  4  for four given requesters. The requestors are devices, such as an IOC  10  or a DMA unit, that request usage of managed resources, such as IO devices, and unmanaged resources, such as Synchronous Dynamic Random Access Memory (SDRAM). There can be one or more requesters of varying types. For example, an IO controller  10  acts as a requestor and a managed resource, where R 0   2  is a requestor only.  
         [0022]     Each of the requestors 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 requestor will have at least one or more communication channels connected to a given local bus that operates in a variety of manners. Each requester will have at least one or more communication channels connected to a given local bus that operates 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.  
         [0023]     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 example of what can be an unmanaged resource is SDRAM where there typically cannot be an occupation of the resource by a single or small group of requesters or is typically not shared by multiple requesters.  
         [0024]     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 operates 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.  
         [0025]     Typically, resources that relate to critical bottlenecks are managed. There can be one or more managed resources. The managed resources illustrated are labeled as follows: Memory controller (Mem Cntl) as  8 , Managed Resource (MR) as  9 , IO Controller (IOC) as  10 , and IO devices as  12 . The managed resources are examples and illustrations of resources that can be used. The immediate disclosure as limiting the number or type of managed resources.  
         [0026]     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 requestor and a managed resource. However, there are a multitude of other mechanisms that possess similar properties to the IOC  10 . The use of an IOC  10  is for the purposes of example and illustration and should not be read to limit. Finally, IO device  11  is connected to the local bus  1  through a sixteenth communication channel  28 , a seventeenth communication channel  29 , the seventh communication channel  26 , and the eighth communication channel  27 . One should also note that the IO device  11  is 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 also be utilized. 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 to limit. Also, each managed resource will have at least one or more communication channels connected to a given local bus that operates in a variety of manners.  
         [0027]     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 requestors 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.  
         [0028]     The Token Manager  12  also solves the problems of denial of service and bottlenecks. Each requestor is assigned a Resource Allocation ID (RAID), which is stored in a register and which is typically related to its access characteristics. Requestors with the same RAID are referred to as a Resource Allocation Group (RAGs). The token manager  12  allocates the usage for each managed resources for a given RAG. The characteristics of the RAGs are determined by software, which can be dynamic. Essentially, each RAG is allocated a predetermined percentage of bandwidth by software, which is based on the desired system performance. In order for a requester within a RAG to communicate with or utilize a given managed resource through an MP, a token should be granted, by the token manager, to the requestor that allows for the communication or utilization. Without a token, there can be no communication or utilization of a managed resource across the MP.  
         [0029]     Regarding the tokens, the Token Manager  12  does not arbitrarily assign the tokens. The Token Manager, instead, generates resource tokens for each RAG by virtue of a rate counter. A given requestor, though, cannot accumulate the tokens, and the sum of all rates for all of the RAGs must not exceed the capabilities of the resource.  
         [0030]     However, in certain cases, such as IO devices  11 , multiple MPs 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 (i.e. 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 I/O devices.  
         [0031]     The requester can utilize the tokens and initiate the communication. A requestor should first generate an internal token request for usage, which includes both a RAID and Managed Resource. The token request is then forwarded to the Token Manager. Upon reception of the given request, the Token Manager will grant the requested token. When all tokens for the MP are granted, the requester is then allowed to perform the pending request.  
         [0032]     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 requester in another RAG or go unused.  
         [0033]     Referring to  FIG. 3  of the drawings, the reference numeral  300  generally designates a flow chart describing the token availability process.  
         [0034]     In order to cross-grant tokens, the Token Manager should make a determination of availability as illustrated in  FIG. 3 . In step  310  and  320 , the Token Manager  12  of  FIG. 2  sets the rate and starts the rate counter. In step  330 , once the rate counter is started, there is a determination as to whether the rate has expired. In step  340 , upon expiration, the available tokens are set. In step  350 , there is a determination as to whether there is a token request. In step  380 , if there is a token request, the token is made available, and the Token Manager  12  of  FIG. 2  again waits until the rate has expired  330 . If there is not a token request, the Token Manager  12  of  FIG. 2  waits until the rate has expired  360 . Once the rate has expired, the token is given away  370 , and the available tokens are set  340 .  
         [0035]     Furthermore, there are also situations where there are unallocated tokens. In other words, there can be tokens that have no particular assignment to a RAG. These unallocated tokens can also be available to requesters with pending requests. However, to obtain the unallocated tokens, the procedure for availability is identical to the procedure illustrated in  FIG. 3 , and a requestor with a pending request must simply wait for a token, either unused or unallocated, to become available.  
         [0036]     Referring to  FIG. 4  of the drawings, the reference numeral  400  generally designates an illustration of example of cross granting of an unused token.  FIG. 4  is to be used for the purposes of example and illustration. There may be one or more RAGs utilized with a given process rate based on the desired performance and capabilities of the system. Moreover, there are at least one or more tokens that each RAG utilizes.  
         [0037]     Overall, there is a rate at which resources are processed  1000 . For both RAG 1  and RAG 2 , there are respective rate counters,  1100  and  1500 , respective token availability,  1200  and  1600 , and respective internal requests,  1400  and  1700 . Also, the internal requests for RAG 1  are labeled A 1  to A 6 , and the internal requests for RAG 2  are labeled B 1  to B 7 . One should note that at time T 1  a token is available for RAG 1 , but there is no pending request in RAG 2 . However, there is a pending request at T 1  within RAG 2 . Hence, the token is cross-granted from RAG 1  to RAG 2  U 1 .  
         [0038]     Hence, the use of a Token Manager in the present invention allows for the preservation of the allocation, which prevents denial of service. By using a Token Manager for the generation and allocation of tokens, bandwidth is guaranteed. Also, resources are utilized to the maximum extend, so as to prevent waste.  
         [0039]     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.