Operating Systems

Sonia requested that Pete Beckman initiate this page. For comments, please contact Pete Beckman. This page is still in development.

QUESTIONS	XPRESS	TG X-Stack	DEGAS	D-TEC	DynAX	X-TUNE	GVR	CORVETTE	SLEEC	PIPER
PI	Ron Brightwell	Shekhar Borkar	Katherine Yelick	Daniel Quinlan	Guang Gao	Mary Hall	Andrew Chien	Koushik Sen	Milind Kulkarni	Martin Schulz
What are the key system calls / features that you need OS/R to support? Examples: exit, read, write, open, close, link, unlink, chdir, time, chmod, clone, uname, execv, etc.	LXK is developed within XPRESS as an independent lightweight kernel to fully support the HPX runtime system and XPI programming interfaces through the RIOS (runtime interface to OS) protocol.	We currently require some method to get memory from the system (equivalent of sbrk) and some method of input/output. The requirements will be extended as we see the need but we want to limit the dependence on system calls to make our runtime as general and applicable to as wide a range of targets as possible.	(DEGAS)	(D-TEC)	(DynAX)	(X-TUNE)	(GVR)	(CORVETTE)	SLEEC	sockets, ptrace access, dynamic linking, timer interrupts/signals, access to hardware counters, file I/O
Does your project implement it's own lightweight thread package, or does it rely on the threads provided by the OS/R? If you implement your own threads, what are the key features that required developing a new implementation? If you don't implement your own thread package, what are the key performance characteristics and APIs needed to support your project?	HPX provides its own lightweight thread package that relies on heavyweight thread execution by the LXK OS. Features required include threads as first class objects, efficient context switch, application dynamic scheduling policies, message-driven remote thread creation.	Our runtime can rely on existing thread (we use pthreads for example) frameworks but we do not need them as we really use the existing threading framework to emulate a computing resource.	(DEGAS)	(D-TEC)	(DynAX)	(X-TUNE)	(GVR)	(CORVETTE)	N/A	relying on native threads, typically pthreads, which is appropriate
Do you currently view virtualization as a key requirement to support your x-stack project? If so, why?	Virtualization is a key requirement for advanced multi-modal use of LXK supporting a diversity of runtime environments including but not limited to conventional legacy codes and future runtime systems like HPX.	No.	(DEGAS)	Virtualization is an orthogonal issue for D-TEC. We do not assume either the presence or absence of virtualization in our work.	(DynAX)	(X-TUNE)	(GVR)	(CORVETTE)	N/A	No
What energy/power and reliability APIs do you expect from the OS/R?	While XPRESS is not explicitly addressing energy and reliability issues, under related support it does incorporate the microcheckpointing compute-validate-commit cycle for reliability and the side-path energy suppression strategy for power reduction. Access to faults detection from hardware and OS is required as is measurements of power and thermal conditions on per socket basis. Control of processor core operation and clocks are required.	We hope that this will all be managed inside the runtime layer and that our EDT and DB programming model will enable the user to be unaware of it. We may, however, allow for some hints from higher level tools (for example having a compiler expose multiple versions of an EDT with differing energy envelopes). The runtime will rely on the underlying system-software/OS to provide introspection capabilities as well as "knobs" to turn (mostly voltage and frequency regulation as well as fine-grained on/off).	(DEGAS)	(D-TEC) - Fault detection notifications from hardware and OS. - Fine-grain power measurements (per socket) - Thermal information (per socket) - Access to DVFS settings	(DynAX)	(X-TUNE)	(GVR)	(CORVETTE)	N/A	Power: Power measurements at varying granularity using processor internal counters and external sensors, for autotuning access to setting DVFS levels or power capping; Resilience: access to fault notification (for corrected and non-corrected errors)
Please describe how parallel programs are "composed" within your project, and what APIs and support is required from the OS/R?	Parallel programs are composed through ParalleX Processes interfaces comprising message-driven method instantiation for value/synchronization passing and data object access. OS support for memory address and global name-space is required.	See the OCR spec.	(DEGAS)	(D-TEC)	(DynAX)	(X-TUNE)	(GVR)	(CORVETTE)	N/A	N/A
What is your model for extreme-scale I/O, and how do you expect the OS/R to support your plans?	OpenX supports a multiplicity of I/O support interfaces from conventional file systems to a unified namespace and asynchronous control (under separate funding).	Proxy call to external hosts.	(DEGAS)	(D-TEC)	(DynAX)	(X-TUNE)	(GVR)	(CORVETTE)	N/A	For PIPER this refers to performance information: hierarchical aggregation through MRNet to reduce data and perform online analysis. OS support required for bootstrapping / optionally, could be integrated with OS backplanes
Does your project include support for multiple, hierarchical, memory regions? If so, how will it be allocated and managed, by your xstack project or my the OS/R? What APIs do you expect the OS/R to support complex and deep memory?	Physical memory is managed by LXK and allocated to HPX ParalleX processes, which aggregate physical blocks to comprise a hierarchy of logical memory resources. Memory is globally accessible through capabilities based addressing and exported process methods.	Yes, OCR supports multiple, hierarchical memory regions. We need support from the underlying system-software/OS to inform the runtime of the regions that it can use and of their characteristics.	(DEGAS)	(D-TEC)	(DynAX)	(X-TUNE)	(GVR)	(CORVETTE)	N/A	N/A