Scribd
Upload
41 views

Fully Dynamic Scheduler For Numerical Computing On Multicore Processors

This document discusses a scheduler for numerical computing on multicore processors. It formulates dynamically evolving task priorities as a Markov chain model. The scheduler considers recent task request history and intensities to determine dynamic priorities, rather than using predefined priorities. Performance results show the scheduler achieves similar performance to other schedulers for smaller problem sizes, but drops to around 6% lower than one scheduler for larger sizes due to dedicating one core only to task insertion.

Uploaded by

Himanshu Mayank
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
41 views

Fully Dynamic Scheduler For Numerical Computing On Multicore Processors

This document discusses a scheduler for numerical computing on multicore processors. It formulates dynamically evolving task priorities as a Markov chain model. The scheduler considers recent task request history and intensities to determine dynamic priorities, rather than using predefined priorities. Performance results show the scheduler achieves similar performance to other schedulers for smaller problem sizes, but drops to around 6% lower than one scheduler for larger sizes due to dedicating one core only to task insertion.

Uploaded by

Himanshu Mayank
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 10

Abstract

Fully Dynamic Scheduler for Numerical Computing on Multicore


Processors
Many algorithms are developed and have been used for
Scheduling the Central Processing Unit (CPU) in a typical
Multiprocessing Environment. In this research a study is carried
on how recently processed requests can be taken up for deciding
the priorities (or) order for scheduling the CPU Processing. The
results are found to be very favorable, as per our simulation
study.
INTRODUCTION
A brief introduction to stochastic processes and
Markov chains: A family of random variables {X (t),
t≥0}is indexed by time parameter t, then process X (t) is
called a stochastic processes (Bhat, 1984; Kendall, 1953).
The set of possible values of Indexing parameter is called
parameter space, which can be either continuous or
discrete. The possible values X (t) assume are called as
states and the set of possible values is called as state-
space, which can be continuous or discrete.
A discrete parameter discrete state space stochastic process
{xn+1 = tn+1/xn = tn, xn-1 = tn-1, xn-2 = tn-2, …, x0 = t0} =
{xn+1 = tn+1/xn = tn} is called as Markov Chain.
This research deals with identifying priorities of
application processing jobs that are arriving at CPU
processing in a multi processing environment. The
priorities identified are mostly for immediate application
i.e., from next moment or for application in immediate
near future i.e., from next cycle onwards.
In this research a CPU Scheduling algorithm is discussed
which will consider the traffic intensity (hit ratio) of the
jobs coming to the CPU in the recent past and most recent
ones and decide on priorities, rather than a predefined
format of priorities these priorities will change from time
to time based on the requests coming to CPU.
Formulating dynamically evolving priorities CPU
scheduling as a Markov chain model: Let T1, T2, T3, T4,
…., Tn be the tasks that are coming for processing at CPU,
let P1, P2, P3, P4 ,…., Pn be the ratios or probabilities of
these tasks based on the past data.
Let Xi be the state of the processor when it is processing
the task T i,Pij be the probability that the processor is
executing the task T j at n + 1st step and in nth step it
executed task T i
Pij = {Xn+1 = j/Xn = i} which can be referred to as
transition probability and the Matrix which gives all the
possible values is referred to as transition probability
matrix.

since the times taken by the CPU are in nano seconds and
the requests coming up to the processor are very high
hence the priorities keep changing from time in the study
taken by the authors it is observed that the priorities
decided are stable for a couple of hours which can be
consider to be the behavior of the system in the long run or
steady-state. The priorities are different for different
schedules hence the priorities are taken accordingly.
The priorities for a specific schedule are computed, as
follows:
The steady state probabilities or the probabilities or
priorities in the long run are π 0, π1, π2, …, π n-1.
Assuming that steady state is achievable, the steady- state
probability vector π = (π 0, π1, π2,……. π n - 1) ; πl > 0, for l
= 0,1,…….., n-1, can be found as a solution to the system
of equations π P = π, in conjunction with

The priorities obtained are used for that slot proved very
efficient effective.
A software code is written for a multiprocessing credit
card transactions environment and the comparative results
showed more than 15% efficiency.
ALGORITHM
1 Creating a Task Similarly to Cilk and SMPSs, functions
implementing parallel tasks have to be side-effect free, which
means they cannot use global variables, etc. In order to
change a regular function call to a task definition, one needs
to:
• declare the function with empty argument list,
• declare the arguments as local variables, and
• get their values by using a macro unpack

2 Invoking a Task
The second step is changing the function call into a task
invocation, which puts the task in the task pool and returns
immediately, leaving the task execution for later (when
dependencies are met and the scheduler decides to run the
task). In order to change a function call into a task invocation,
one needs to:
• replace the function call with a call to the Insert Task()
function,
• pass the task name (pointer) as the first parameter, and
• follow each original parameter with its size and direction.

3. Scheduler Implementation
Currently the scheduler targets small-scale, multi-socket
shared memory systems based on multicore processors. The
main design principle behind the scheduler is implementation
of the dataflow model, where scheduling is based on data
dependencies between tasks in the task graph. The second
principle is constrained use of resources with strict bounds on
space and time complexity.
CODE:

/****
* Example 1: A Traditional DynC Cooperatively Multithreaded Program
****/
main(void) {
/* CoData structures for two named tasks */
CoData t1, t2;

while(1) {
/* Keyboard handler */
costate {
while(1) {
waitfor(kbhit());
switch(getchar()) {
case '-':
/* Stop one of the currently running tasks */
if (isCoRunning(&t1)) CoPause(&t1);
else if (isCoRunning(&t2)) CoPause(&t2);
else printf("No tasks running.\n");
break;

case '+':
/* Start one of the currently stopped tasks */
if (!isCoRunning(&t1)) CoResume(&t1);
else if (!isCoRunning(&t2)) CoResume(&t2);
else printf("Both tasks running.\n");
break;
}
}
}

/* Task 1 (initially on) */


costate t1 init_on {
while (1) {
/* Task 1 work goes here. */
printf("Task 1\n");
yield;
}
}

/* Task 2 (initially off) */


costate t2 {
while (1) {
/* Task 2 work goes here. */
printf("Task 2\n");
yield;
}
}
}
}

Since DynamicC does not support named yields directly, programs such as the example
above would have to simulate a named yield by performing a CoPause() on each intervening
costatement. For example:

while(1) {
costate foo always_on {
printf("Foo");
if (problem_detected()) {
CoPause(bar);
CoPause(baz);
yield;
} else {
printf("No problem detected.\n");
}
}

costate bar always_on {


printf("Bar");
}

costate baz always_on {


printf("Baz");
}

costate recovery_thread always_on {


fix_problem();
CoResume(bar);
CoResume(baz);
}
}
Performance Results
The tile LU algorithm was chosen for preliminary performance
experiments. Figure 6 shows performance numbers for the
scheduler versus SMPSs and the static schedule, utilized by the
PLASMA library, on a 2.4 GHz quad-socket quad-core . The
tile size of 200 was used with inner-blocking of 40. These are
typical values for achieving good asymptotic performance.

inner-blocking of 40. These are typical values for achieving


good asymptotic performance. They do, however, render
suboptimal performance for small problem sizes. One can
observe that, for this particular problem, SMPSs loses
marginally to the static schedule for smaller problem sizes and
eventually catches up for larger problems. The scheduler
presented in this article performs as good as SMPSs for smaller
problem sizes, but eventually drops below SMPSs’
performance by a margin of roughly 6 %, which is due to one
core devoted to inserting the tasks and not participating in
executing them.

You might also like