Learning to Share

MotivationDisk 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

AcknowledgementsThis 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 algorithmThe 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 Scheduling1 (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.1Joel 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. 189-194, Skamania, Washington, June 13-14, 2005.

Request Queue

Request Queue

T

TT

T

TT

T

T

T

TT

50% 50%

For Example...

Basic algorithmAlgorithm

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 tokensOriginal 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 haveAdvantage 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

BorrowingOriginal 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

0 1

A

CB

0

-1 1

A

CB

0

0 1

A

CB

Node B receives a request. It has no tokens, so it requests to borrow...

OriginalThe 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.

ModifiedNode 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 capacitiesTo 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

ConclusionThe 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 Limit Limit

Gwendolyn EinfeldUCSC 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 YESService request!

NO

Can I borrow tokens?

NO

YES

Tokens