Learning to Share Motivation Disk schedulers are responsible for determining when processes are allowed to access the hard disk. They must balance multiple processes and users trying to simultaneously access the same hard disk space. Real-time processes—such as video or other multimedia, introduce further constraints. These processes cannot wait for others to complete before they are given access or the user experiences reduced performance. Solution Acknowledgements This research was conducted under the advisorship of Scott Brandt and the Storage Systems Research Center. The work was completed as part of UCSC's SURF-IT summer undergraduate research program, an NSF CISE REU Site. Disk scheduling using a hierarchical token bucket filtering algorithm The modified algorithm The HDS algorithm was modified to address three questions:  What should the RATE of tokens entering the tree be?  HOW MANY tokens should be in the tree at any one time?  What should the RULES OF BORROWING be? What is a token bucket filter? A token bucket filter assigns processes a bucket which is filled with tokens. The tokens may be cashed in as needed for disk time and the buckets are refilled according to a set rate. A version of token bucket filtering known as Hierarchical Disk Scheduling 1 (HDS) uses a hierarchy of token buckets to assign disk time. In HDS, nodes may borrow unused tokens from their parent’s buckets if they run out of their own tokens. 1 Joel Wu, Scott Banachowski, and Scott A. Brandt. “Hierarchical Disk Sharing for Multimedia Systems” ACM International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV 2005), pp , Skamania, Washington, June 13-14, Request Queue T T T T T T T T T T T 50% For Example... Basic algorithm Algorithm functions  Update token rate  Replenish tokens  Use tokens  Can make request?  Borrow tokens  Make request from queue  Add request to queue Rate and number of tokens Original  A token rate is assigned to each node based on a global rate and the node’s reservation  Nodes replenish their buckets by calculating how long it has been since they received tokens and multiplying by their token rate  The number of tokens corresponds to the global rate Modified  Tokens are recycled so that the rate of tokens leaving the tree equals the rate of tokens entering  Entering tokens are assigned to nodes based on probability  The number of tokens available equals the number of outstanding requests the disk can have Advantage  This disk controls the rate instead of an estimated average rate  Prevents overloading when disk is operating slowly  Allows full utilization of resources when disk is operating faster than average Borrowing Original  If a node does not have tokens, it passes the request to its parent  If the parent can service the request, it does so  If no node in the hierarchy has tokens, the original child node waits until it receives more Modified  If a node does not have tokens, it checks if any of its parent nodes does  If a parent can service the request, the child node uses a token from both its own bucket and its parent’s bucket  If no node in the hierarchy can service the request, the node waits until a token arrives and then checks if it can use or borrow the token 1 01 A CB 0 1 A CB 0 01 A CB Node B receives a request. It has no tokens, so it requests to borrow... Original The request is passed the request to B’s parent, ‘A’. ‘A’ has one token and uses it. Node B does not participate in the borrow. Modified Node B checks if its parent, ‘A’, has tokens. ‘A’ does, so it borrows the token from ‘A’, causing its own count to go negative, and its parent to go to 0. Bucket capacities To prevent nodes from hoarding disk space that they aren’t using, each node has a limit on how many tokens it can accrue. The result is that if a node stops using tokens, it also stops receiving tokens. This also prevents nodes from sinking too low into debt. Borrowing rules  A bucket can have a negative token count if it has been borrowing  Bucket capacities prevent buckets from stock-piling tokens they are not using  A node can never service a request without using a token from its own bucket  Nodes that have tokens get priority over nodes without tokens In the simulation above, each node serviced requests until time 40 when Node B stopped receiving requests. In the “No Limit” graph, Node B continues to receive tokens. In the “Limit” graph, Node B stops receiving tokens, allowing Node A to receive more. Below, the count of tokens in each node’s bucket is tracked. Notice that having the limit prevents Node A from sinking as far into debt. No Limit Limit Conclusion The modified algorithm facilitates borrowing more fairly than the original. Processes have strict rules that limit the extent to which they may borrow tokens or store them up. Additionally, the modifications to the rate ensures that available disk time will be fully utilized without the danger of overloading. No LimitLimit Gwendolyn Einfeld UCSC Storage Systems Research Center Each node is entitled to a percentage of incoming tokens Node may represent a user, process or group of processes Requests are sent to a queue where they wait for an available token The number of tokens in a parent node is equal to the sum of tokens in its children Arriving tokens are added to both the parent and child nodes. Likewise, when a token is used it is subtracted from the child node and any parent(s) Is there a request in my queue? Do I have tokens? NO YES Service request! NO Can I borrow tokens? NO YES Tokens