Results 1 - 10
of
52
Exokernel: An Operating System Architecture for Application-Level Resource Management
, 1995
"... We describe an operating system architecture that securely multiplexes machine resources while permitting an unprecedented degree of application-specific customization of traditional operating system abstractions. By abstracting physical hardware resources, traditional operating systems have signifi ..."
Abstract
-
Cited by 732 (24 self)
- Add to MetaCart
(Show Context)
We describe an operating system architecture that securely multiplexes machine resources while permitting an unprecedented degree of application-specific customization of traditional operating system abstractions. By abstracting physical hardware resources, traditional operating systems have significantly limited the performance, flexibility, and functionality of applications. The exokernel architecture removes these limitations by allowing untrusted software to implement traditional operating system abstractions entirely at application-level. We have implemented a prototype exokernel-based system that includes Aegis, an exokernel, and ExOS, an untrusted application-level operating system. Aegis defines the low-level interface to machine resources. Applications can allocate and use machine resources, efficiently handle events, and participate in resource revocation. Measurements show that most primitive Aegis operations are 10–100 times faster than Ultrix,a mature monolithic UNIX operating system. ExOS implements processes, virtual memory, and inter-process communication abstractions entirely within a library. Measurements show that ExOS’s application-level virtual memory and IPC primitives are 5–50 times faster than Ultrix’s primitives. These results demonstrate that the exokernel operating system design is practical and offers an excellent combination of performance and flexibility. 1
Extensibility, safety and performance in the SPIN operating system
, 1995
"... This paper describes the motivation, architecture and performance of SPIN, an extensible operating system. SPIN provides an extension infrastructure, together with a core set of extensible services, that allow applications to safely change the operating system's interface and implementation. Ex ..."
Abstract
-
Cited by 458 (16 self)
- Add to MetaCart
This paper describes the motivation, architecture and performance of SPIN, an extensible operating system. SPIN provides an extension infrastructure, together with a core set of extensible services, that allow applications to safely change the operating system's interface and implementation. Extensions allow an application to specialize the underlying operating system in order to achieve a particular level of performance and functionality. SPIN uses language and link-time mechanisms to inexpensively export ne-grained interfaces to operating system services. Extensions are written in a type safe language, and are dynamically linked into the operating system kernel. This approach o ers extensions rapid access to system services, while protecting the operating system code executing within the kernel address space. SPIN and its extensions are written in Modula-3 and run on DEC Alpha workstations. 1
Exterminate all operating system abstractions
- PROCEEDINGS OF THE 5TH WORKSHOP ON HOT TOPICS IN OPERATING SYSTEMS HOTOS-V
, 1995
"... The defining tragedy of the operating systems community has been the definition of an operating system as software that both multiplexes and abstracts the hardware is based on the assumption that it is possible both to define abstractions that are appropriate for all areas and to implement them to p ..."
Abstract
-
Cited by 66 (1 self)
- Add to MetaCart
The defining tragedy of the operating systems community has been the definition of an operating system as software that both multiplexes and abstracts the hardware is based on the assumption that it is possible both to define abstractions that are appropriate for all areas and to implement them to perform efficiently in all situations. We believe that the fallacy of this quixotic goal is self-evident, and that the operating system problems of the last two decades (poor performance, poor reliability, poor adaptability, and in exibility) can be traced back to it. The solution we propose is simple: complete elimination of operating system abstractions by lowering the operating system interface to the hardware level.
Practical, transparent operating system support for superpages
- SIGOPS Oper. Syst. Rev
, 2002
"... Most general-purpose processors provide support for memory pages of large sizes, called superpages. Superpages enable each entry in the translation lookaside buffer (TLB) to map a large physical memory region into a virtual address space. This dramatically increases TLB coverage, reduces TLB misses, ..."
Abstract
-
Cited by 60 (5 self)
- Add to MetaCart
Most general-purpose processors provide support for memory pages of large sizes, called superpages. Superpages enable each entry in the translation lookaside buffer (TLB) to map a large physical memory region into a virtual address space. This dramatically increases TLB coverage, reduces TLB misses, and promises performance improvements for many applications. However, supporting superpages poses several challenges to the operating system, in terms of superpage allocation and promotion tradeoffs, fragmentation control, etc. We analyze these issues, and propose the design of an effective superpage management system. We implement it in FreeBSD on the Alpha CPU, and evaluate it on real workloads and benchmarks. We obtain substantial performance benefits, often exceeding 30%; these benefits are sustained even under stressful workload scenarios. 1
Virtual Memory in Contemporary Microprocessors
, 1998
"... this article, especially Joel Emer, Jerry Huck, Mike Upton, and Robert Yung for their comments and insights into the workings of the Alpha, PA-RISC, IA-32, and SPARC architectures. The Defense Advanced Research Projects Agency under DARPA/ ARO contract DAAH04-94-G-0327 partially supported this work. ..."
Abstract
-
Cited by 41 (10 self)
- Add to MetaCart
this article, especially Joel Emer, Jerry Huck, Mike Upton, and Robert Yung for their comments and insights into the workings of the Alpha, PA-RISC, IA-32, and SPARC architectures. The Defense Advanced Research Projects Agency under DARPA/ ARO contract DAAH04-94-G-0327 partially supported this work. References
A look at several memory management units, TLB-refill mechanisms, and page table organizations
- in Proceedings of the Eighth International Conference on Architectural Support for Programming Languages and Operating Systems. ACM
, 1998
"... Virtual memory is a staple in modem systems, though there is little agreement on how its functionality is to be implemented on either the hardware or software side of the interface. The myriad of design choices and incompatible hardware mechanisms suggests potential performance problems, especially ..."
Abstract
-
Cited by 38 (3 self)
- Add to MetaCart
(Show Context)
Virtual memory is a staple in modem systems, though there is little agreement on how its functionality is to be implemented on either the hardware or software side of the interface. The myriad of design choices and incompatible hardware mechanisms suggests potential performance problems, especially since increasing numbers of sys-tems (even embedded systems) are using memory management. A comparative study of the implementation choices in virtual memory should therefore aid system-level designers. This paper compares several virtual memory designs, including combinations of hierarchical and inverted page tables on hardware-managed and software-managed translation lookaside buffers (TLBs). The simulations show that systems are fairly sensitive to TLB size; that interrupts already account for a large portion of memory-manage-ment overhead and can become a significant factor as processors exe-cute more concurrent instructions; and that if one includes the cache misses inflicted on applications by the VM system, the total VM over-head is roughly twice what was thought (10-200/o rather than 5-10%). 1
A new page table for 64-bit address spaces
, 1995
"... Most computer architectures are moving to 64-bit virtual address spaces. We first discuss how this change impacts conventional linear, forwardmapped, and hashed page tables. We then introduce a new page table data structure—clustered page table—that can be viewed as a hashed page table augmented wit ..."
Abstract
-
Cited by 31 (0 self)
- Add to MetaCart
(Show Context)
Most computer architectures are moving to 64-bit virtual address spaces. We first discuss how this change impacts conventional linear, forwardmapped, and hashed page tables. We then introduce a new page table data structure—clustered page table—that can be viewed as a hashed page table augmented with subblocking. Specifically, it associates mapping information for several pages (e.g., sixteen) with a single virtual tag and next pointer. Simulation results with several workloads show that clustered page tables use less memory than alternatives without adversely affecting page table access time. Since physical address space use is also increasing, computer architects are using new techniques—
Deconstructing Process Isolation
- In Proceedings of the 2006 Workshop on Memory System Performance and Correctness
, 2006
"... Most operating systems enforce process isolation through hardware protection mechanisms such as memory segmentation, page mapping, and differentiated user and kernel instructions. Singularity is a new operating system that uses software mechanisms to enforce process isolation. A software isolated pr ..."
Abstract
-
Cited by 28 (4 self)
- Add to MetaCart
(Show Context)
Most operating systems enforce process isolation through hardware protection mechanisms such as memory segmentation, page mapping, and differentiated user and kernel instructions. Singularity is a new operating system that uses software mechanisms to enforce process isolation. A software isolated process (SIP) is a process whose boundaries are established by language safety rules and enforced by static type checking. SIPs provide a low cost isolation mechanism that provides failure isolation and fast inter-process communication. To compare the performance of Singularity’s SIPs against traditional isolation techniques, we implemented an optional hardware isolation mechanism. Protection domains are hardware-enforced address spaces, which can contain one or more SIPs. Domains can either run at the kernel’s privilege level or be fully isolated from the kernel and run at the normal application privilege level. With protection domains, we can construct Singularity configurations that are similar to micro-kernel and monolithic kernel systems. We found that hardware-based isolation incurs non-trivial performance costs (up to 25-33%) and complicates system implementation. Software isolation has less than 5 % overhead on these benchmarks. The lower run-time cost of SIPs makes their use feasible at a finer granularity than conventional processes. However, hardware isolation remains valuable as a defense-in-depth against potential failures in software isolation mechanisms. Singularity’s ability to employ hardware isolation selectively enables careful balancing of the costs and benefits of each isolation technique.
Characterizing the d-TLB Behavior of SPEC CPU2000 Benchmarks
- In Proceedings of the 2002 ACM SIGMETRICS International Conference on Measurement and Modeling of Computer Systems
, 2002
"... Despite the numerous optimization and evaluation studies that have been conducted with TLBs over the years, there is still a deficiency in an indepth understanding of TLB characteristics from an application angle. This paper presents a detailed characterization study of the TLB behavior of the SPEC ..."
Abstract
-
Cited by 17 (0 self)
- Add to MetaCart
(Show Context)
Despite the numerous optimization and evaluation studies that have been conducted with TLBs over the years, there is still a deficiency in an indepth understanding of TLB characteristics from an application angle. This paper presents a detailed characterization study of the TLB behavior of the SPEC CPU2000 benchmark suite. The contributions of this work are in identifying important application characteristics for TLB studies, quantifying the SPEC2000 application behavior for these characteristics, as well as making pronouncements and suggestions for future research based on these results.
