1. Research on Asymmetric-aware Hypervisor Scheduler Project overview 6/4

2. Outline Introduction Current Status Working Plans

3. Outline Introduction Current Status Working Plans

4. Goal Generate scheduling plans that minimize the power consumption while satisfying the requirement of virtual cores on asymmetric multi-core platform. 4

5. Outline Introduction Current Status Working Plans

6. Current Status Design and implement the three-phase scheduler based on Xen scheduling framework. Solve some problems in proto-type ◦ Remove the overhead caused by “false-busy”, i.e. assign vCPU that is not runnable to cores. Conduct experiments with different settings. Paper submission: SOCA’15.

7. Experimental Settings workload: Coremark ◦ Light, medium, heavy Different scenarios ◦ 2 dual-core guest virtual machines. ◦ 2 quad-core guest virtual machines. ◦ 4 dual-core guest virtual machines. Compare with credit-based scheduler and AASH.

8. Results

9. Outline Introduction Current Status Working Plans

10. Short-term Plan Improve the stability and reduce the overhead of the scheduler. Improve the implementation of the three- phase scheduling algorithm. Add cpufreq to Dom0 and control the frequency of physical cores. (Issac) 10

11. Mid-term Plan Support more extensive and complicated workloads. Enhance Xen to support runtime DVFS. Leverage on DVFS of the physical cores. ◦ The scheduler can guide/affect the DVFS mechanism by generating core frequency in the scheduling plan. 11

12. Power Consumption of Different Frequencies Frequency(MHz) Power consumption of the cluster(W) Average power consumption of a core(W) A57 core cluster 4500.130.03 8000.370.15 11000.790.36 A53 core cluster 4500.090.01625 7000.190.04125 8500.320.07375 Idle power consumption: [A57] 0.07 W; [A53] 0.025W

13. Long-term Plan Leverage on task information from guest virtual machines. ◦ Retrieve the information by hyper-calls. ◦ Change the cpumask of task in order to create big and little virtual cores.

14. Information Retrieved Install a kernel module that record the information from top. ◦ Filter out system/background processes by PID and/or process name. ◦ Focus on processes with high priority/low nice value. ◦ Multi-thread process.

15. Implementation Issue Two different methods: ◦ The kernel module collects the information and decide the cpumask for tasks.  The hyper-call only passes the resource requirement/big-little virtual core setting to hypervisor. ◦ The kernel module collects the information, then pass the filtered info to hypervisor.  Need a component in hypervisor to analyze and make decisions.

16. Discussion