Embed Size (px)
DESCRIPTION
Il mio primo seminario in isislab sul green scheduling
Citation preview
GREEN SCHEDULING
Vincenzo De Maio
OUTLINE
Introduction Theoretical Model
Computation model Energy consumption model Throttling model
Simulator Green Heuristics Results and future works References
WHAT IS GREEN COMPUTING?
“The study and practice of designing, manufacturing, using, and
disposing of computers, servers, and associated subsystems such
as monitors, printers, storage devices, and networking and
communications systems efficiently and effectively with minimal or
no impact on the environment.”[1]Professor Dr San MurugesanFaculty of ManagementMultimedia UniversityCyberjaya, Malaysia,
WHY DOES GREEN COMPUTING MATTERS?
Some numbers: 2 google searches = 14CO2 grams (as boiling a
kettle!) (Alex Wissner-Gross, Harvard University physicist) [2][3]
Windows 7 + Microsoft office 2007 requires 70 times more RAM than Windows 98 + Office 2000 to write exactly the same text or send the same email[4]
In 2010, servers were responsible of the 2.5% of the total energy consumption of the USA. A Further 2.5% were used for their cooling.[5]
It was estimated that by 2020, servers would use more of the world's energy than air travel if current trends continued[5]
FURTHER REFERENCES
Green500 (www.green500.com) GreenIT (www.greenit.fr) CO2Stats (www.co2stats.com)
WHY GREEN SCHEDULING?
A green scheduler could provide Energy-oriented task assignment
Setting the correct power level for current workload Improved use of the power management
Learning power usage profile of job types
Could be a part of the Operating System power management
WHAT DO WE WANT FROM A GREEN SCHEDULER?
Efficiency Simplicity Time is money!
OUTLINE
Introduction Theoretical Model
Computation model Energy consumption model Throttling model
Simulator Green Heuristics Results and future works References
COMPUTATION MODEL
Tasks usually depends on each other DAGs: Directed Acyclic Graphs
If there’s a dependency between task u and v, we put an arc between nodes u and v
COMPUTATION MODEL
SP-DAGs: Serial parallel DAGs A DAG with 2 terminals
(source and target) and an arc between them is a SP-DAG
Made by parallel and series composition of other SP-DAGs
WHY SP-DAGS?
They describe several significant class of computation (for instance divide and conquer algorithms)
They are the natural abstraction for several parallel programming languages (such as CILK) [10]
We can recognize if a DAG is an SP-DAG in linear time
We can easily transform an arbitrary DAG in an SP-DAG in linear time, using SP-ization
LEGO® DAGS
Assessing the computational benefits of AREA-Oriented DAG-Scheduling (Gennaro Cordasco, Rosario De Chiara, Arnold L. Rosenberg) 2009
SP-DAGs made by a repertoire of Connected Bipartite Building Blocks DAGs representing the various subcomputations
FURTHER DEFINITIONS ON DAGS AND SP-DAGS
A node in the DAG could be Unelegible Elegible Assigned/executed
Schedule: Topological sort of the DAG Obtained by a rule for selecting which elegible
node to execute at each step of computation
v has at least a non-executed
parent
All v’s parent have been executed
v has been scheduled for execution or
executed
CRITICAL PATH
Longest path from the source to the sink
Why is so important?
It’s clear to see that we can’t finish our computation before executing each node on the critical path
So, time critical path execution takes it’s a trivial lower bound.
FURTHER DEFINITIONS ON DAGS AND SP-DAGS
Yield of a node: number of nodes that become elegible when the given node completes his execution.
: Elegible nodes at step i in schedule Σ Σ)
OUTLINE
Introduction Theoretical Model
Computation model Energy consumption model Throttling model
Simulator Green Heuristics Results and projected works References
ENERGY CONSUMPTION MODEL
We need a realistic model for energy consumption
We should check Circuits dissipation Throttling models
ENERGY CONSUMPTION MODEL
CMOS Circuit dissipation:
(we won’t consider short circuit power and leakage)
We assume a linear relationship between voltage and frequency
ENERGY CONSUMPTION MODEL
Our model:
Where:
clock cycles per second C enclosesseveralconstantslikecapacitance, k and clock multiplier
OUTLINE
Introduction Theoretical Model
Computation model Energy consumption model Throttling model
Simulator Green Heuristics Results and projected works References
CPU THROTTLING MODELS
Which is the common throttling model used by modern processors?
ACPI: Advanced Configuration and Power-management Interface[6]
A fully platform-independent standard that provides: Monitoring Configuring Hardware discovering Power management
Defines power states for every device
PERFORMANCE VS POWER STATES
Power states: C0: Operational power state C1: Halt state C2: Stop-clock C3: Sleep
Performance states: P0: Higher state P1: Less than P0, frequency / voltage scaled Pn: Less than Pn-1, frequancy/voltage scaled
In our model, we implement only C0 power state and P0,P1,P2 Performance states.
OUR THROTTLING MODEL
We use a DFS (DynamicFrequencyScaling) Model, assumingthatscalingdoesn’taddenergyoverhead
P0: P1: P2:
FURTHER CONSIDERATIONS
In our model, an idle core consumes 0 We do not track the algorithm execution
energy We do not track energy dissipated by
memory using Energy is unbounded We’re assuming that you can set a single
core throttling
OUTLINE
Introduction Theoretical Model
Computation model Energy consumption model Throttling model
Simulator Green Heuristics Results and future works References
THE SIMULATOR
We implemented this model in a DAG-Scheduling simulator, Providing classes and methods to calculate
energy consumption Implementing the energy model we discussed
earlier Paying attention to extensibility
A TYPICAL SIMULATION
1. Loads a DAG2. Computes graph critical path3. Initializes schedulers that needs to be
tested4. Executes schedulers on the given graphs for
a given number of trials (usually 100, due to randomness influencing schedulers)
5. At the end of iterations, it collects statistics about the executions, specifically
6. Makespan (min, max, average)7. Energy consumption average
8. Repeats on each DAG
HOW WE IMPLEMENTED THE MODEL
Our focus: Extensibility We wanted our simulator to support multiple
kind of models Providing
Core abstraction Throttling level abstraction Energy aware scheduler abstraction
Totally decoupled from core and throttling level
Making easier to add Different scheduling algorithms Different core types Different energy models
CORE ABSTRACTION
A core can Execute tasks Set its own throttling level Track its power consumption
Problem: different cores could implement different throttling strategies
Solution: Every core has its own throttling levels array Throttling level is a nested class in the core
implementation
THROTTLING LEVEL ABSTRACTION
A throttling level contains Informations about frequency and consumption Methods to calculate
Due date of a task at a given level (lesser the level, slower the task execution)
Power consumption at a given level
ENERGY PACKAGE
Core interface We assume that every core can execute task and
set his own throttling Abstract class ThrottlingLevel
Implements a throttling level, with energy consumption info and frequency.
Class DummyCore Core base implementation
Class DefaultThrottlingLevel DummyCore nested class, implements our
performance states
CORE INTERFACE/** * Execute a task on this core * @param node The node that models the task * @param length Task length if executed at max power * @return the real task length (this could differ from input * if Core is set to a different throttling level) */public double executeTask(ICONode node, double length);/** * Sets a core power consumption to his current throttling level * idle consumption */public void setIdle();/** * Sets the core to a greater power level */public void increaseThrottlingLevel();/** * Sets the core to a lesser power level */public void decreaseThrottlingLevel();
THROTTLINGLEVEL/** * This method calculates the power consumption for a * given task length, according to power consumption unit * and other parameters, according to programmer's will that * implements it. * * @param length The task length * @return Power consumption for this task */abstract double getPowerConsumptionPerTask(double length);
/** * This method calculates how task length is modified * for the given throttling level * * @param length ideal length of the task * @return the real task length for the given throttling level */abstract double getRealLength(double length);
THROTTLING LEVEL INITIALIZATIONpublic void initializeThrottlingLevels(double hardwareConstant,
double maxFreq, double maxVoltage, int throttlingLevels) {
this.levels = new ThrottlingLevel[throttlingLevels];
for( int i = 0; i < throttlingLevels - 1 ; i++ ){
double numerator,denominator;
numerator = i + 1.0;
denominator = i + 2.0;
double fraction = numerator/denominator;
levels[i] = new DefaultThrottlingLevel("LEVEL"+i,
hardwareConstant, fraction * maxFreq, fraction * maxVoltage);
}
this.levels[throttlingLevels - 1] = new DefaultThrottlingLevel("LEVEL"+(throttlingLevels-1),
hardwareConstant, maxFreq, maxVoltage);
//necessary for correct use of increase and decrease
Arrays.sort(levels);
//by default we set the maximum power level
this.currentThrottlingLevel = levels[2];
this.throttlingLevelIndex = 2;
this.dissipatedPower = 0.0;
}
ENERGY AWARE SCHEDULER ABSTRACTION
An energy aware scheduler has to Work with different types of cores Track the makespan and the energy consumption Implement logic for
Core selection Elegible node selection Choosing the right throttling level
ENERGY AWARE SCHEDULER PACKAGE
CoreSelector Implements free core selection strategy (In those
tests we use DefaultCoreSelector class) EnergyAwareScheduler
Base for each scheduler tracking energy consumption
INSPECTING ENERGYAWARESCHEDULER CLASS/**
* Istantiates a new EnergyAwareScheduler
* @param numCores number of cores
* @param coreClass class that models the desired core type
* @throws InstantiationException
* @throws IllegalAccessException
* @throws IllegalArgumentException if numCores <= 0
*/
public EnergyAwareScheduler(int numCores, Class<? extends Core> coreClass)
throws InstantiationException, IllegalAccessException, IllegalArgumentException
/**
* Calculates the task length on a given core
* @param coreIndex index of the core in the corePool
* @param eventLength ideal length of the task
* @param node node to be executed
* @return the task length if executed on coreIndex core
*/
protected double getTimeOffsetForCore(int coreIndex, double eventLength,
ICONode node)
INSPECTING ENERGYAWARESCHEDULER CLASS/**
*Sets thtottling for core that are going to execute a task in this step
*@param coreIndex: the core id
*/
protected void setBusyThrottling(int coreIndex)
/**
*Sets throttling state for core that will remain idle
*/
protected void setIdleThrottling()
public double getTotalPowerConsumption()
private void calculateIdleConsumptions()
WHAT ABOUT SCHEDULING?
Schedule steps are implemented using the TimeLine Object
A priority queue containing two types of TimeEvent processorsArrives clientFinishes
At each scheduling step removes the first event from the TimeLine
Scheduling logic is implemented in the runBatchedMakespan method
Further initialization are made in the initBatchedMakespan method
RUNBATCHEDMAKESPAN METHOD
1. While ( executedNode != target)2. Event := timeline.pollNextEvent();3. setOverallThrottlingLevel();4. Switch(Event)5. Case(processorsArrives)
6. := min(availableCores,elegibleNodesNum)7. For i := 0 to
8. nextNode := getNextElegibleNode();9. coreIndex := coreSelector.getCoreIndex();10. corePool[coreIndex].setBusy();11. setBusyThrottling(coreIndex);12. timeOffset := getTimeOffsetForCore(coreIndex,
eventLength, nextNode);13. timeline.add(new TimeEvent(event.getTime+
timeOffset,ClientFinishes,nextNode)
RUNBATCHEDMAKESPANMETHOD
14. Case(clientFinishes)15. executedNode = event.getNode();16. Execute(executedNode);17. corePool[event.getOwnerCore()].setFree();
DEFAULT STRATEGIES
getNextElegibleCore() is abstract (every core has to implement it)
setBusyThrottling(coreIndex) by default sets the maximum throttling level, as setOverallThrottlingLevel()
Further initializations are made in the initBatchedMakespan method
WHAT ABOUT CORE SELECTION?
Core selection is implemented as a different class implementing the CoreSelector interface
CoreSelector provides the getCoreIndex method
In our simulation we use only the DefaultCoreSelector, that simply takes the highest frequency free core
OUTLINE
Introduction Theoretical Model
Computation model Energy consumption model Throttling model
Simulator Green Heuristics Results and projected works References
GREEN HEURISTICS
CPScheduler AOSPDScheduler TFIHeuristicScheduler MarathonHeuristic
Every heuristic has been implemented as an EnergyAwareScheduler subclass
CRITICAL PATH BASED SCHEDULING
1. Computes graph critical path2. Select free core with highest energy3. Set core to maximum power4. Select node with maximum distance from
the sink
To implement this scheduler, only method getNextElegibleCore() has been overwritten
AOSPD SCHEDULING
On scheduling DAGs to maximize AREA (Gennaro Cordasco, Arnold L. Rosenberg)
An idea from Internet Computing scenario It’s quite impossible to determine when new
processors become available for task execution So… What we can do? Solutions:
Maximize the AREA at each execution step GREAT! Not always possibile [7]
Maximize the average AREA over the execution steps Good! Always possible!
MORE ON AOSPD SCHEDULING At step 1, we have to
choose B or C for execution
To maximize AREA at step 1, we choose C
What happens in step 2? Choosing elegible nodes
in step 2 we can’t maximize AREA
To maximize AREA in step 2 we should have chosen B, that was not AREA-Maximizing for step 1
ADDING ENERGY TRACKING AOSPD SCHEDULING
We already had this algorithm implemented, without energy tracking
How to plug AOSPD in? Solution:
Extending the EnergyAwareScheduler Refactoring class so that we have the
getNextElegibleNode()
TFI HEURISTIC
The idea: if we have to wait for a task that requires much more time than others, we could slow down the faster ones to save energy
TFI: Max due date for critical path value i
TFI HEURISTIC
1. Computes graph critical path2. Select free core with highest frequency3. Sort elegible nodes by their critical path value and yield4. Find maximum due date5. TFINode := node with maximum critical path value and
due date6. TFI:= maximum task length
7. For i:=1 to 9. Node := elegibleNodes[i]10. If Node == TFINode
11. execute Node at max power
12. Else if (elegibleNodes.size() <numCores)13. Execute our node at minimum throttling level that keeps his length
lesser than TFI
14. Else execute node at default throttling level
MARATHON HEURISTIC
The idea: Our problem reminds a Marathon… We have to come first… … and possibly alive (with enough energy to
come back home) Being lazier we’ll save more energy
How should we run a marathon? According to my uncle:
It’s better to preserve an average pace than squandering energies to run faster for a short stretch
When you can’t overtake (road too narrow or you’re too tired), it’s better to slow down a little waiting for best conditions
MARATHON HEURISTIC
1. Computes graph critical path2. Select free core with highest frequency3. Sort elegible nodes by their critical path
value and Yield
4. Front := sum of yields of the first nodes5. For i := 1 to
7. Node := elegibleNodes[i]8. If front + n <= numcores – (numcores / DELTA)
9. execute Node at minimum power
10. Else11. Execute Node at average power
OUTLINE
Introduction Theoretical Model
Computation model Energy consumption model Throttling model
Simulator Green Heuristics Results and projected works References
ASSESSING RESULTS
Remember “time is money”? Solution:
Remember Area-time complexity in VLSI design?[8][9]
We use Energy-Time complexity to plot our schedulers performances
Lesser the score, better the scheduler
TESTS
Test parameters: Number of cores: 4, 8, 16 Standard deviation: 1, 2, 4, 8
Standard deviation influences task due date, which are generated by a Gaussian distribution with mean 1.0 and stdev in the given set
4 CORES, STDEV = 1
4 CORES, STDEV = 2
4 CORES, STDEV = 4
4 CORES, STDEV = 8
8 CORES, STDEV = 1
8 CORES, STDEV = 2
8 CORES, STDEV = 4
8 CORES, STDEV = 8
16 CORES, STDEV = 1
16 CORES, STDEV = 2
16 CORES, STDEV = 8
CONCLUSIONS
We can’t obtain a makespan better than the critical path scheduling
AREA and Yield considerations doesn’t seem to add much more in terms of energy savings At least in a multicore scenario… Probably we should focus only on critical path
Task due dates doesn’t seem to influence makespan too much
FUTURE WORKS
Tracking scheduler efficiency Adding a model for idle core’s consumption Considering a “finite energy” model Extend it in a volunteer computing scenario We could consider a scenario with many core
on different dies Adding an extra cost to switch them on
Adding thermal parameters
OUTLINE
Introduction Theoretical Model
Computation model Energy consumption model Throttling model
Simulator Green Heuristics Results and projected works References
REFERENCES
1) Harnessing GREEN IT: Principles and pratice (San Murugesan, 2009)
2) "Research reveals environmental impact of Google searches.". Fox News. 2009-01-12. http://www.foxnews.com/story/0,2933,479127,00.html. Retrieved 2009-01-15.
3) “Powering a Google search". Official Google Blog. Google. http://googleblog.blogspot.com/2009/01/powering-google-search.html. Retrieved 2009-10-01.
4) "Office suite require 70 times more memory than 10 years ago.". GreenIT.fr. 2010-05-24. http://www.greenit.fr/article/logiciels/logiciel-la-cle-de-l-obsolescence-programmee-du-materiel-informatique-2748. Retrieved 2010-05-24.
REFERENCES
5) "ARM chief calls for low-drain wireless". The Inquirer. 29 June 2010. http://www.theinquirer.net/inquirer/news/1719749/arm-chief-calls-low-drain-wireless. Retrieved 30 June 2010.
6) Advanced Configuration and Power Interface Specification, 2010 (www.acpi.info)
7) Toward a theory for scheduling dags in internet-based computing (G. Malewicz, A. L. Rosenberg, M. Yurkewych, 2006)
8) Lower bound for VLSI (Richard J. Lipton, Robert Sedgewick, 1981)
REFERENCES
9. Area-time complexity for VLSI (C.D. Thompson, 1979)
10. Cilk: an efficient multithreaded runtime system (R.D. Blumofe, C.F. Joerg, B.C. Kuszmaul, C.E. Leiserson, K. H. Randall, Y. Zhou) 5° ACM SIGPLAN Symp. On Principles and practices of Parallel Programming (PPoPP ‘95)
THAT’S ALL, FOLKS!
Thanks for your
attention!
