Antônio Augusto Fröhlich Gilles Pokam Tientcheu Wolfgang Schöder-Preikschat

1. EPOS and Myrinet: Effective Communication Support for Parallel Applications Running on Clusters of Workstations Antônio Augusto Fröhlich Gilles Pokam Tientcheu Wolfgang Schöder-Preikschat mailto:guto@first.gmd.de http://www.first.gmd.de/~guto May 2000

2. Outline • Introduction • Application-orientation systems • Component-based systems • EPOS • Design • Framework • Generation • Tools • Conclusion

3. Introduction high performance X all purpose, global, generic • There is no best “general” solution • Each (class of) application has particular demands

4. Applicaiton-orientation • Each application deserves its own run-time support system • Set of applications that will run on top of the operating system and their requirements • Isn’t known until run-time => dynamic adaptation • Can be determined before run-time => static configuration • Parallel and embedded applications • Adaptability and configurability • Component-based?

5. “a file system” usability maintainability a few complex components component granularity many simple components customizability reusability performance “a queue link” Component-orientation

6. Do I have to take this junk as well? The component I need is not there! a few complex components component granularity many simple components What is this component for? What is the difference to that other one? How do I use it? The Gap to Applications(Motivation for EPOS)

7. EPOS: Embedded Parallel Operating System • EPOS operating system • Application-driven assemblage of system components • EPOS components • Statically configurable, application ready system abstractions • EPOS and the real world • Intelligent visual tools for configuration • Invisibility • Standard libraries (Posix files, libc, libstdc++, libm) • Standard APIs (Posix threads, MPI)

8. System Abstraction system micro-components EPOS System Abstractions • Application ready components • Independent from execution scenario • Examples: • A thread on a given scheduling policy • NOT a thread for one processor, or for multi-tasking

9. Scenario Adapters EPOS Scenario Adapters • Adapt existing system abstractions for a given execution scenario • Adapt system micro-components to grant the semantics dictated by a given execution scenario • Examples: • An SMP adapter • A secure remote invocation adapter

10. Inflated Interfaces file thread task communicator synchronizer memory segment EPOS Inflated Interfaces • Export system abstractions to applications • Well-known to application programmers • Comprehensive • Promote requirement analysis • Examples: • thread • communicator • synchronizer • Not a fat interface • if intersection => subset

11. <<interface>> <<interface>> selectively realize partially realize key realization 1 realization 3 realization 2 realization 1 3 2 Partial and Selective Realization Relationships • System configuration is basically restricted to the setting of selective realize keys

12. EPOS Framework • Static metaprogrammed • Metaprograms run at compile-time • (Almost) no run-time overhead • Implemented as C++ templates • System abstraction implementation • Wrapped • No allocation or sharing control • No cross-domain invocation • Always embedded in the application • Controlled • Allocation and sharing control is possible • Cross-domain invocation is possible • Embedded in the application or packed in a kernel

13. <<select>> scenario adapter <<select>> realization EPOS FrameworkWrapped System Abstraction Application inflated interface wrapper

14. EPOS FrameworkControlled System Abstraction Application <<select>> id basic stub <<select>> message Inflated interface procedure call stub message exchange stub <<select>> stub handle <select>> scenario adapter <<select>> id <<select>> realization <<select>> server state procedure call server message exchange server basic server System

15. Automatic Generation • Application refers to inflated interfaces • Requirement analyzer parses the application searching for inflated interfaces references • Which interfaces are referred to? • How they are referred to? • Expert system select the realizations that better match the referred inflated interfaces • An application-oriented operating system is compiled

16. complex application program code = new Segment(buffer, size); task = new Task(code, data); thread = new Thread(task, &entry_func, priority, SUSPENDED, arguments); mutex->entry(); Mailbox mailbox; mailbox >> message; File file(name); file << mailbox; mailboxes threads tasks syntactic analyzer files mutex segments Requirement Analysis

17. real application program (MPI) Channel link(destination); link << mesage; syntactic analyzer links flat memory Requirement Analysis

18. Context Information • We need context information • new Thread(task, &func) => location? • mailbox << message => protocol? • Absence of Task => single-task? • Buildup databases • Scenario dependencies • Target machine description

19. mailboxes threads tasks execution scenario required Inflated interfaces files monitors segments Execution Scenario + =

20. application interfaces scenario adapters system micro-components system abstractions Application-oriented EPOS

21. Conclusions • EPOS doesn’t grant the tailored OS to be optimal • When several realizations fulfill the requirements, the selection is arbitrary • Profiling could help • EPOS framework overhead is close to zero • Tools are being implemented • System abstraction repository is growing • First real applications are being negotiate