1 / 16

Donald S. Miller

Effects of the Single Address Space Paradigm on CPU and OS Design for a Distributed Computer System. Donald S. Miller. What’s a Paradigm?.

keziah
Download Presentation

Donald S. Miller

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Effects of the Single Address Space Paradigmon CPU and OS Design for aDistributed Computer System Donald S. Miller

  2. What’s a Paradigm? • Constellation of beliefs, values, techniques and so on shared by the members of a given community that implicitly define the legitimate problems and methods of a research field for succeeding generations of practitioners1 • attracts an enduring group of adherents away from competing modes of scientific activity • sufficiently open-ended to leave all sorts of problems for the group of practitioners to resolve • Includes law theory, application and instrumentation together • Examples: Aristotle’s physics, Ptolemaic astronomy, Galileo’s motion studies, Copernican astronomy, Newtonian mechanics, Einstein's relativity and • Process-Oriented OSs and Single Address Space Operating Systems ____________________ 1. The Structure of Scientific Revolutions, 3rd Edition, Thomas S. Kuhn, University of Chicago Press, 1996.

  3. Process-Oriented Paradigm • Each process runs in it’s own virtual address space • virtual addresses are (process) context dependent • Process boundaries encapsulate and bind temporary virtual address spaces, execution state, objects, protection domains and principals • Persistent storage is in a separate namespace - the file system • Message-based communication or RPC on top of message passing is the most prevalent mechanism for data exchange and synchronization between executing entities • Page-based object granularity • Threads encapsulated within a process - domain crossing and machine migration without an address space and thread context switch essentially impossible • Layered system structure - operating system kernel and services and user-level servers and programs layered on top of each other

  4. Process-Oriented Paradigm (continued) • Obtaining operating system services requires a domain crossing AND entry into privileged supervisor mode • Process and data migration difficult - involves creating a new namespace for data (DSM) and dealing with distinct machine namespaces for code • Difficult to directly support OOD and OOP - preprocessors and OS run-time systems are needed • OS support for protection implementation protection policy are intertwined • Access authorization, resource accounting and name services typically require kernel services or intervention • Copy set management is usually page-based and requires broadcasts reducing scalability • Network-wide fault tolerance requires additional mechanisms

  5. Process-Oriented Paradigm (concluded) • Examples of Process-Oriented operating systems • Industrial • MULTICS, UNIX, MVS, Mach, Chorus, VMS, NT • Research • Exokernel, L4, SPIN

  6. Single Address Space Paradigm • All programs run in a single virtual address space that covers all levels of the memory hierarchy, all nodes of a network and persists for the life of the computer system. This leads to the following 5 properties. 1. Permanent and unique binding of all data and code to virtual addresses. 2. The ability to freely reassociate memory objects, access rights, protection domains, virtual addresses, principals and threads. 3. A single network-wide namespace backed by the local demand paged memory management on every node and that includes all levels of the memory cache hierarchy. 4. Object, thread and protection domain mobility across the entire network-wide virtual address namespace. 5. Separation of ownership of code and ownership of execution of a computation.

  7. Single Address Space Paradigm (continued) • All programs run in the same virtual address space • virtual addresses are not context dependent • Execution state, objects, protection domains and principals are not bound to virtual addresses and hence not bound to each other • Persistent storage is in the same virtual address namespace • Shared memory is the most prevalent mechanism for data exchange and synchronization • Object granularity can be independent of page granularity • Threads can travel throughout the virtual address space without an address space switch or a thread context switch • System architecture can be flat and modular - operating system services, environment servers and user-level programs can be made accessible to each other and themselves via simple procedure calls and returns

  8. Single Address Space Paradigm (continued) • Obtaining operating system services is orthogonal to entry into privileged supervisor mode • Process and Data Migration is straight-forward - objects and threads exist at the same virtual addresses on all nodes; kernel structures can be replicated or represented by surrogates on different nodes • OOD and OOP can be directly supported - a protection domain can translate directly into an instantiation of an object class available at the user level - preprocessors and OS run-time systems are not needed; base classes can be extended via overrides at the user level • Clean separation of OS support for protection implementation and user-level definition of protection policy is simple • Access authorization, resource accounting and name services can be done at the user level • The common virtual address space provides simple scaleable per object copy set management and a lowest level cache for fault tolerance

  9. Single Address Space Paradigm (concluded) • Examples of Single Address Space Operating Systems • Without additional protection hardware assistance • Opal, Mungi, Arius, Carthage (KFRPC) • With additional protection hardware assistance • AS/400, MONADS, ToM, Carthage (FRPC), Sombrero

  10. Sombrero Principals

  11. Layered system structure - operating system kernel and services and user-level servers and programs layered on top of each other System architecture can be flat and modular - operating system services, environment servers and user-level programs can be made accessible to each other and themselves via simple procedure calls and returns SYSTEM ARCHITECTUREProcess Oriented OS Single Address Space OS

  12. Obtaining operating system services requires a domain crossing AND entry into privileged supervisor mode Obtaining operating system services is orthogonal to entry into privileged supervisor mode SYSTEM ARCHITECTUREProcess Oriented OS Single Address Space OS

  13. Difficult to directly support OOD and OOP - preprocessors and OS run-time systems are needed OOD and OOP can be directly supported - a protection domain can translate directly into an instantiation of an object class available at the user level - preprocessors and OS run-time systems are not needed; base classes can be extended via overrides at the user level SYSTEM ARCHITECTUREProcess Oriented OS Single Address Space OS

  14. OS support for protection implementation protection policy are intertwined Clean separation of OS support for protection implementation and user-level definition of protection policy is simple SYSTEM ARCHITECTUREProcess Oriented OS Single Address Space OS

  15. Access authorization, resource accounting and name services typically require kernel services or intervention Access authorization, resource accounting and name services can be done at the user level SYSTEM ARCHITECTUREProcess Oriented OS Single Address Space OS

More Related