1 / 1

:: Conclusions :: Sysctl produced data that strongly support the initial hypothesis.

Senior Project – Computer Science - 2010 james the GIANT killer: evaluating kernel locking schemes in james toy Advisor – Professor David Hemmendinger. kernel log. virtual mem. sysctl. scheduler. sysctl. kernel log. sched. mem. :: Conclusions ::

minor
Download Presentation

:: Conclusions :: Sysctl produced data that strongly support the initial hypothesis.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Senior Project – Computer Science - 2010james the GIANT killer: evaluating kernel locking schemes injames toyAdvisor – Professor David Hemmendinger kernel log virtual mem sysctl scheduler sysctl kernel log sched mem :: Conclusions :: Sysctl produced data that strongly support the initial hypothesis. • 1/2% system increase of throughput • Max time saved ~30 seconds (2 hrs build) Klog test did not produce useful data because the locking mechanisms are around a device node not a msg_buffer. Extending FGLs to more subsystems increases throughput What really matters Goal was to determine if: • FGL is detrimental to the system (complication) (NO) • FGL is significantly faster than GIANT_LOCKING in a small subsystem like sysctl. (YES) The FGL implementation scales well. • :: Problem :: • Why do we need locking? • Race conditions • “bad” “dog” • Threads race each other on context switches • Possible incorrect result : “bda dog” (interleaving) • Alternative correct result: “dog” “bad” • The most important things is correct results • Incorrect in-kernel code affects the entire system • Locking prevents Race Conditions GIANT_LOCKs only allow one thread in the kernel at a time FGLs only go around shared data structures : “critical sections” in subsystems :: Background :: GIANT_LOCK vs. Fine Grained Locks (FGLs) • :: Design :: • Method of evaluation (comparison of FGL and GIANT) • Two separate branches in a version control system • Specific subsystems being targeted and why • Klog: prints kernel events -- low traffic • Sysctl: manages kernel variables -- higher traffic • (control) • Tests designed to hit specific subsystems • multi-threaded make sysctl • kernel driver to make klog calls • (locking profiler) • Analyzes when locks are acquired and relinquished • TOO MUCH DATA • Correctness and how it was achieved • Correctness • Race conditions arise from writing to a shared resource • Readers pick up shared lock; writers pick up exclusive. • The FGL follows the GIANT_LOCKING logic; however, it is a more detailed implementation that is concerned with locating critical sections and protecting them. • Process • Branch and Replace GIANT code with FGL • Rebuild kernels in both configurations & automate testing and result generation with cron scripts • :: Affiliation to the FreeBSD Project :: • The code and methods generated in this project has been shared with several other developers of the FreeBSD project and is now in the FreeBSD–CURRENT branch as of its completion a few months ago. • The LOCK_PROFILER(9) was instrumental in generating valid test results for this project. The profiler was written by several “core” FreeBSD developers. A big thanks goes out to those talented developers! A PRODUCTION Thanks dh; I could not have done this without you. =jt

More Related