Futuristic UC Berkeley OS Tessellation Controls Discrete 'Manycore' Resources 28
coondoggie writes "At the Design Automation Conference (DAC) here this week, John Kubiatowicz, professor in the UC Berkeley computer science division, offered a preview of Tessellation, describing it as an operating system for the future where surfaces with sensors, such as walls and tables in rooms, for example, could be utilized via touch or audio command to summon up multimedia and other applications. The UC Berkeley Tessellation website says Tessellation is targeted at existing and future so-called 'manycore' based systems that have large numbers of processors, or cores on a single chip. Currently, the operating system runs on Intel multicore hardware as well as the Research Accelerator for Multiple Processors (RAMP) multicore emulation platform."
Sporadic scheduling (Score:5, Interesting)
Some of what they're doing with resource guarantees is like QNX's "sporadic scheduling" [qnx.com]. The idea is that you can guarantee a thread something like 1ms of CPU time every 10ms. This is useful for near-real-time tasks which need a bounded guarantee of responsiveness but don't need to preempt everything else immediately. Most UI activity is in this category. With lots of UI devices, including ones like vision systems that need serious compute resources, you need either something like this, or dedicated hardware for each device.
On top of sporadic scheduling there should be a resource allocator which doesn't let you overcommit resources. So if something is allowed to run, it will run at the required speed.
This is very useful in industrial process control and robotics. The use case for human interfaces is less convincing.
Re:Sporadic scheduling (Score:3, Interesting)
My Thesis was about implementing a similar concept for Linux (http://saadi.sourceforge.net); it was working well in 2006, but I did not have the time to maintain it. The concept you describe has one flaw: For energy efficiency, most CPUs support digital voltage scaling. Therefore a time based CPU garantee is useles. Instead the guarantee should be about CPU cycles per time period.
With that in place, it could be used to increase energy efficiency as well because the frequency can be optimized to just match the guarantees.
One remaining problem is the required calibration for each CPU. A video player might require different amounts of CPU cycles depending on CPU architecture.