I've been busy this summer, between my GSOC project, my academic progress, and life in general. I thought I should catalog some of the work that I've done for the GSOC 2010. I have previously talked about my work to port RTEMS to SPARC V9. Well, I had a GSOC project accepted for the RTEMS project which I have been working on this summer. The remainder of this blog post is excerpted from my project proposal and describes what I have been doing lately. The full project proposal can be read online at: http://code.google.com/p/rtems-sched/wiki/ModularSuperCoreSchedulerProject.
My project is to refactor the RTEMS task scheduler to make it more modular. The current RTEMS scheduler is tightly coupled with the thread management code. This tight coupling prevents easy implementation and testing of alternate scheduling mechanisms. Refactoring the scheduler into a new SuperCore Scheduler Manager enables RTEMS developers (namely, me) to explore new scheduling mechanisms.
After finishing my project, the RTEMS scheduler internal data structures will be encapsulated in a module that provides a protected interface such that none of the thread management code directly touches scheduling data.
Perhaps the most important outcome of my project will be enabling exploration of scheduling for symmetric multiprocessing (SMP) and multicore platforms. An SMP system is a closely-coupled system with multiple CPU chips interconnected with main memory; a multicore system is even more tightly coupled, with multiple CPUs interconnected on a single chip. Although RTEMS currently supports multiprocessing systems, the support is designed for coarse-grained systems. Each processing element (core) runs a separate RTEMS application and executive, and communication is routed through a portion of shared memory. Scheduling decisions are made locally at each core, and tasks are not able to migrate between cores.
Although my project will not provide SMP support, the goal of refactoring the scheduler is to facilitate implementing an SMP scheduler, so care will be taken to make sure the interface does not enforce any policies that might deter an SMP scheduler. By supporting global scheduling decisions and task migration, RTEMS will be able to balance a processing load across multiple CPUs. Further, unifying the executive across all the cores in the system allows RTEMS to make smarter decisions and to reduce the effort of end users in deploying SMP and multicore configurations.
It has been a pleasure to work with you this summer and I look forward to all your code being merged. It is an important piece of work for the reasons you cite and a few others:
ReplyDelete+ configuring alternate scheduling algorithms.
You yourself have provided an EDF scheduler as a user selectable alternative. I don't remember if you implemented the "simple" scheduler we discussed which is just a single priority ordered Ready list but even though it is O(number of tasks), it is ideal for low memory environments.
+ research into schedulers
You defined a scheduler interface which allows end users to externally implemented a scheduler. This opens the door to relatively painless scheduler research.
My scheduler simulator needs to be merged. This lets one investigate and debug schedule algorithms inside RTEMS but not have to debug them in "real systems". You can script all events and watch what the scheduler decides to do.
So this is important for TinyRTEMS, alternative schedulers, scheduler research AND SMP. It hits all the use cases. :)