Difference between revisions of "Operating Systems"
|Line 57:||Line 57:|
Revision as of 21:59, 9 May 2014
Sonia requested that Pete Beckman initiate this page. For comments, please contact Pete Beckman. This page is still in development.
|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.||(TG)||(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.||(TG)||(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.||(TG)||(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.||(TG)||(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.||(TG)||(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).||(TG)||(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.||(TG)||(DEGAS)||(D-TEC)||(DynAX)||(X-TUNE)||(GVR)||(CORVETTE)||N/A||N/A|