MOS 2nd Report
< Development of CPU Scheduling and Monitoring Tool with respect to process>
Topic: Understanding CPU scheduler and implementation of monitoring tool to recognize of the process characteristics
Due date: mid-night Nov. 29. 2017
Environments: Oracle VM VirtualBox, Ubuntu16.04 LTS
1. Purpose
Recently, it is difficult to allocation of CPU resources in CFS(Completely Fairness Scheduler)of LINUX as CPU scheduler. It has inefficient allocation scheme in order to allocate CPU resource.The purpose of this report is understanding CPU scheduler and implementation of monitoring tool to recognize of the process characteristics.
2. Goal of Report
A. Development of monitoring tool for realizing the characteristic of process
¦ After identify the list of processes on host system, extract the information of process(PID, process name etc.) from specific process(CPU bound, I/O bound)
¦ Determine the strategy of CPU scheduling and store to DB by using the extract information.
¦ Apply the strategy of CPU scheduling when the process resume after DB should be checked
B. Add two system calls
¦ PID, which it gets the monitoring tool, transfer to CPU scheduler
C. Analysis and modify of CPU scheduler code
¦ Apply the proper strategy of 2 PIDs with respect to characteristic
¦ CPU bound process completes first.
3. Report Implementation
A. Environments
¦ Create the virtual machine on VirtualBox and hypervisor, and then install LINUX(available to use Native Linux)
¦ Use Ubuntu 16.04 LTS
¦ New compile : Kernel Version4.4.0.
B. Kernel
¦ Add Two System Calls
i. Schedule_faster: get PID(faster_PID) from monitoring tool, transfer to CPU scheduler.
ii. Schedule_slower: get PID(slower_PID) from monitoring tool, transfer to CPU scheduler..
¦ Analysis and modify CPU scheduler code
iii. About the transferred 2 PID, you have to modify CPU scheduler code as followed; faster_PID executes fast, slower_PID executes slow based on scheduling strategy
iv. LINUX has the matric(vruntime) to determine priority by using CPU scheduler based on the priority. Therefore we obtain the goal by modifying the code to recalculate this matric.
C. Monitoring tool
¦ Read the required information (PID, name) using Procfs.
¦ The process information is monitored every predetermined cycle (0.5s) to detect whether a new process has been executed. If it is a specific process, the policy is determined and stored in the DB.
¦ After the specific process is terminated, the process is re-executed to record the change in the result of the policy change by the monitoring tool(to assume that the PIDs will differ from each other in the first and second runs.)
D. Benchmark program
¦ Provide two Applications(benchmark1, benchmark2)
¦ You should run both programs in advance and determine what characteristics they have and reflect them in the production of monitoring tools.
¦ With the monitoring tool running, run a total of two times to observe the changes.
E. need to be modified in the kernel as followed;
¦ System Call
i. (linux)/arch/x86/entry/syscalls/syscall_64.tblà A collection of symbolic information about the names of system call functions
ii. (linux)/include/linux/syscalls.hà Prototype definition of added system call functions
iii. (linux)/kernel/sched_faster.c
iv. (linux)/kernel/sched_slower.c à The source of the system call to addFile name and file number can be freely set by individual
v. (linux)/kernel/Makefileà modify system call to be included in kernel make
¦ CPU 스케줄러
vi. (linux)/include/linux/sched.hàSched_entity, cfs_rq Data Structure Definition
vii. (kernel)/kernel/sched/fair.cà task update Entry Point of CPU schedulerà faster_PID: Modifying the code so that vruntime increases 100 times slower slower_PID: Modify the code so that vruntime increases 100 times faster
F. References
¦ Interface to transfer data (PID) from the added system call to the scheduler
i. Using EXPORT_SYMBOL macro.
¦ How to obtain a PID from the Schedule_entity that is currently being updated
ii. If you look closely at the function that updates Vruntime, you can get a hint.
(Obtain PID using macros provided by the kernel)
4. Output Format
A. DB list and benchmark execution time output before and after monitoring execution
B. Change in performance measurement results (for example
5. Restrictions
A. Modify monitoring and CPU scheduling policies for only two given benchmarks
6. Method of submission
A. By using E-Class(based on submission date)
B. Lists of submission files
¦ Report
¦ Modified or added filesand Makefile
¦ Attach a brief description (ReadMe.txt) of attached files if necessary
7. criteria of evaluation
A. Department, Student NO, Name, submission date
B. Investigating Procfs
C. Identify benchmark characteristics
D. Scheduler Corrections and Reasons (Include a description of the code and its code in the report)
E. Checking normal operation of monitoring tool (Include a description of the code and its code in the report)
F. Benchmark performance measurement results
G. Analysis of results
8. Notes
A. Report file name : “MOS2_student NO.tar” or “MOS2_student NO.tar.gz” + Report, Log, ReadMe.txtè”MOS2_student NO.zip
B. Source files should never submit entire Linux kernel sources.
C. Must be able to compile and run in a Linux environment of the same environment.
D. Submission Place : New Eng. Bld. # 6115
E. Report pages : 15 pages
