Project News

Service-Oriented Operating System Architectures: Solution for Future HPC?

Print
Last Updated on Saturday, 13 July 2013

As the impact of the memory wall increases, new methods are needed to better exploit the available storage and reduce the amount of cache misses. Traditional monolithic operating systems are not ready for this move, since they create considerable overhead on cache and data communication. Within its 3 years runtime, the S(o)OS project investigated, how operating systems need to change in order to offer the necessary performance in future systems. The result of this investigation consisted in a modular architecture that is highly promising for large scale applications dedicated to specific tasks, such as video stream processing, fluid dynamics simulation etc.

The architecture exposes a high capability for adaptivity with only minimal stress on workload and, more importantly, communication and storage. Implicitly, the S(o)OS architecture adds less overhead to the normal application execution than normal operating systems would do in a large scale, and in particular in a many-core environment. Classical operating systems are not designed for such environments and implicitly create data locks, coordination interactions and memory overloads for the simple reason that their own data and operation structure is not aligned to distributed execution. Further to this, traditional operating systems are devised to cater for a wide degree of application cases and destination platforms, thus delivering a highly complex product that covers a wide scope of needs as best as possible. This implicitly must disrespect application cases with highly specialised needs, such as in particular High Performance Computing.

The S(o)OS architecture is aligned to these circumstances from the very beginning: not only is its data structure and coordination protocol distributed from the very beginning, its capability set has also been considerably restricted so as to cater ideally for specific needs. Due to the modularity of the architecture, the individual capabilities can be easily adjusted to individual use cases and infrastructures, as well as combined in a fashion that supports even more complex cases.

At the same time, however, this means that the architecture is not well suited for cases that fully exploit complex OS capabilities, such as graphical user interfaces etc. and that expect that the main execution work is performed by the operating system itself. In other words, it is not well suited for applications that require a traditional operating system. S(o)OS is in its nature closer to DOS, with a highly single-task oriented and low level execution support in the first instance, but as opposed to low level operating systems, geared towards large scale parallel execution. As such, operating systems following the S(o)OS concepts are ideal for applications / algorithms that actually only require little support from the operating system in the first instance. With its organisation, S(o)OS supports in particular distributed memory organisation and communication across a wide diversity of infrastructures, thus e.g. enabling highly performant and portable execution of PGAS code.

For an overview over the main results in S(o)OS, please check out our website,

Thursday the 17th. Sponsored under FP7-ICT-2009.8.1, Grant Agreement No. 248465. This website is monitored by Google Analytics. IP addresses are anonymized.
Copyright 2012

©