Evaluating the bugs mentioned in the paper https://www.ece.ubc.ca/~sasha/papers/eurosys16-final29.pdf
The process for evaluating the bugs:
- Used a server with 8 cores (instead of 64) and 2 NUMA nodes (instead of 8)
- Forward the patches to 4.15 kernel, compile, reboot
- Compile the sched_profiler.c and insert the module in this kernel
- Rerun the tests as mentioned in the paper. (Instead of the Oracle workload ran make -j <num_cores>
- Gather the data by cat /proc/sched_profiler > output.txt
- Run the tools/visualizations_4.1/plots/generate_rows_sched_profiler.sh to generate the graphs
- Analyze the graphs as follows: a) The load graphs plot load for every pixel for all the processors on y-axis and the time on the x-axis. If you frequently see a pattern of white - i.e the load was minimum and a red i.e high load on the same vertical segment, then that indicates a bug. This is because in the string_to_color.php, the load is plotted from white to green to blue to red to pink as the load increases. b) The runqueue graphs plot the size of the runqueue for every cpu. Again for every time slice, the y axis represents all the cpus, the x axis indicates the time. So for a given cpu at a given time, the pixel color indicates the runqueue length. If the runqueue is empty the color is white. It keeps progressing to a red when the runqueue length is more than 5. Hence when you see a frequent pattern of white a red or cyan together then that indicates a Bug.
- I did not see any bugs mentioned in the paper. One bug I could identify the fix in the code. Another bug could not be reproduced because of lack of better server, 3rd bug needs more testing - but my work did not reproduce it. Eyeballing the code, waking up on a processor seems fine. The 4th bug was easily reproduced before and cannot be done now. Eyeballing the code the cpu bring up seems to update the domains and groups fine.