## 3 The Proposed Architecture
### Data Center
#### 3.1.3 Semi-Preemptive Mode Resource Allocation
(2) Resource Preemption  
There are two cases in which preemption is required. The first is that when a type-1 request arrives, no resource nodes of all levels that can serve type-1 requests are available. Maybe some of R2% of o-level-2 resource nodes are available, but due to our allocation policy, they cannot be allocated to serve type-1 requests. The second case is that when a type-2 request arrives, no level-2 (including R2% and R2'%), level-3 and R1'% of level-1 resource nodes are available. When the first case occurs, Resource Broker first preempts an o-level-1 resource node that is serving a type-3 or type-2 request in the situation where the one serving a type-3 request will be chosen first (see Table 8). Of course, these o-level-1 resource nodes are those belonging to the R1'% portion. O-level-1 resource nodes that are serving type-1 requests will not be preempted. However, if no o-level-1 resource nodes are now serving type-3 requests, one of the o-level-1 resource nodes now serving a level-2 request will be preempted. If all o-level-1 resource nodes are serving type-1 requests, some o-level-2 resource nodes will be preempted. The row type-1 in Table 8 summarizes the preemption priorities. If no resource nodes are preempted, implying that all resources nodes are executing type-1 requests, the type-1 request will be re-enqueued in the type-1 global queue. In the second case, only o-level-2 resource nodes that are serving type-3 requests (Of course, these resource nodes belong to the R2'% portion) will be preempted to serve the type-2 request. However, if no o-level-2 resource nodes are running type-3 requests, then one of the o-level-1 \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Req. Nodes** & \begin{tabular}{c} **O-level-1** \\ **resource nodes** \\ **of R1 \%** \\ \end{tabular} & \begin{tabular}{c} **O-level-1** \\ **resource nodes** \\ **of R1’\%** \\ \end{tabular} & \begin{tabular}{c} **O-level-2** \\ **resource nodes** \\ **of R2\%** \\ \end{tabular} & \
\begin{tabular}{c} **O-level-3** \\ **resource nodes** \\ **of R2\%** \\ \end{tabular} &
\begin{tabular}{c} **Level-3** \\ **resource nodes** \\ **of R2\%** \\ \end{tabular} \\ \hline Type-1 & 1 & 2 & - & 3 & 4 \\ Type-2 & - & 4 & 1 & 2 & 3 \\ Type-3 & - & 3 & - & 2 & 1 \\ \hline \hline \end{tabular}
\end{table} 
Table 7: The percentages of o-level-_i_ resource nodes that can serve type-_j_ requests, \(1\leq i,j\leq 3\). resource nodes now serving type-3 requests will be preempted. If no o-level-1 and o-level-2 resource nodes are preempted, indicating that they are all running type-1 and/or type-2 requests, one of the level-3 resource nodes currently serving type-3 requests will be preempted. If no resource nodes have been preempted, implying all resource nodes are running type-1 and/or type-2 requests, the request will be re-enqueued to the type-2 global queue. When a type-3 request arrives, and no level-3, level-2 of R2'%, level-1 of R1'% nodes are available (see Table 7), the request will be re-enqueued to the type-3 global queue. No preemption will be performed. Once a resource node N is preempted, the request that N is now serving, e.g., request \(y\), will be re-enqueued to N's waiting queue, instead of its global queue, as the highest priority request to be executed by N when N finishes the job of the preempting request, and those requests which are now in N's waiting queue will stay in the queue following their original waiting sequence to wait to be served by [PERSON].