Eric J. Koldinger, Jeffrey S. Chase, and Susan J. Eggers. Architectural support for singleaddress -space operating systems. In Proc. 5th ASPLOS, pages 175--86, 1992.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....Furthermore, they require an additional cache (the PKRs) on the processor core (although the lookup latency can be hidden in the pipeline) and the TLB remains on the processor core. An alternative approach, the protection look aside buffer (PLB) completely decouples protection and translation [36]. In this scheme, all protection data is removed from the TLB, which can then be moved off core if a virtually addressed L1 cache is used. The PLB is essentially a TLB with no translation information (making it smaller) and thus has essentially the same drawbacks as a classical TLB: it is in the ....

Eric J. Koldinger, Jeffrey S. Chase, and Susan J. Eggers. Architectural support for singleaddress -space operating systems. In Proc. 5th ASPLOS, pages 175--86, 1992.

....as it eases debugging. Furthermore, CE works by only supporting a limited number of processes (32) which is unacceptable for a general purpose system. Hence, what can be learned from the CE approach is quite limited. A number of alternate hardware approaches have been proposed. Koldinger et al. KCE92] proposed a protection lookaside buffer (PLB) as a means to separate protection and translation, and thus better utilise the valuable TLB real estate. Their proposal was specifically aimed at single address space systems [CLFL94, HEV 98] which are characterised by a process independent ....

Eric J. Koldinger, Jeffrey S. Chase, and Susan J. Eggers. Architectural support for single-address-space operating systems. In Proceedings of the 5th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), pages 175--86, 1992. 14

....page on some TLBs and so translation information will be duplicated and the coverage of the TLB reduced. The desired granularity of translation and protection are also not identical and this can, for example, cause problems such as false sharing on systems that implement distributed shared memory [25]. When a page needs to be swapped in from secondary storage, another page will need to be swapped out to make room for this. A replacement algorithm selects the page with the goal of choosing the page that will least likely be accessed in the future. Since an optimal algorithm is not possible ....

....component of this thesis. 2.6.1.3 Protection without the TLB If the TLB is removed from the cache hit path an alternative mechanism needs to be provided for memory protection. V V cache PLB Virtual address . Figure 2.17: Protection lookaside buffer. Koldinger et al. [25] discuss models for separating protection from the TLB, the domain page model and the page group model. The domain page model is implemented by placing protection information in a separate cache called the protection lookaside buffer (PLB) The PLB is similar to a conventional TLB with respect to ....

Eric J. Koldinger, Jeffrey S. Chase, and Susan J. Eggers. Architectural Support for Single Address Space Operating Systems. Technical Report 92-03-10, University of Washington, July 1992.

....expected performance and demonstrates feasibility of the reliable and efficient datastore implementation based on the concept of distributed shared virtual memory. 5 Related Work Distributed object systems over virtual memory are described and implemented in several papers and projects, e.g. [4, 11, 12, 2]. however, neither load balancing nor object (de)clustering is considered in these projects. Distributed persistent object directory based on shared virtual memory is described in [5, 8, 1] but the architecture proposed there does not take into account performance issues. Distributed dynamic ....

E. Koldinger, J. Chase, and S. Eggers. Architectural Support for Single Address Space Operating Systems. In Proceedings of the 5th International Conference on Architectural Support for Programming Languages and Operating Systems - ASPLOS, Oct. 1992.

....loadable OS kernel modules (such as in Linux) all run in the kernel s unprotected address space, leading to potential reliability and security problems. Figure 1 illustrates a general protection system and is based on the diagrams in [17] and [18] Each column represents one protection domain [16] while each row represents a range of memory ad Memory Addresses None Read only Read write Execute read Protection domains Permissions Key 0 0xFFF. Figure 1: A visual depiction of multiple memory protection domains within a single shared address space. dresses. The address space can be ....

....meet the different requirement by placing each thread in a separate address space and then mapping in physical memory pages to the same virtual address in each address context. These systems fail the small requirement because permissions granularity is at the level of pages. Page group systems [16], such as HP PA RISC and PowerPC, define protection domains by which page groups (collections of memory pages) are accessible. Every domain that has access to a page group sees the same permissions for all pages in the group, violating the different requirement. They also violate the small ....

[Article contains additional citation context not shown here]

E. J. Koldinger, J. S. Chase, and S. J. Eggers. Architectural support for single address space operating systems. In ASPLOS-V, pages 175--186, 1992.

....significant attention of researches during few last years. The interest is especially stimulated by appearance of 64 bit addressing, which makes possible to explore single virtual address space for several computers for implementation of operating systems and persistent object stores (e.g. [6, 10, 11, 8]) Another implementation of distributed shared virtual memory is proposed in [2] and used for implementation of distributed object directory. However, in this paper we are not particularly interested in the implementation architecture of distributed shared memory and we describe our concurrency ....

E. Koldinger, J. Chase, and S. Eggers. Architectural Support for Single Address Space Operating Systems. In Proceedings of the 5th International Conference on Architectural Support for Programming Languages and Operating Systems - ASPLOS, Oct. 1992.

....limitations. However, the advent of machines such as the DEC Alpha [35] and the MIPS R4000 [17] which (logically) support a 64 bit address has created renewed interest in this approach. A number of research groups have suggested that this is an appropriate direction for modern operating systems [20]. Such an approach is tempting since it fits in well with the goals of orthogonal persistence, i.e. to abstract over all physical attributes of data. However, there are some difficulties: ii. Most persistent systems rely upon a checkpointing mechanism to establish a consistent state on stable ....

....techniques, the first option could take a considerable amount of time due to I O bandwidth. If a single address space is shared by all processes, the ability to protect separate areas of the address space must be provided. Whilst protection systems have been designed for large address spaces [20], they are still only experimental designs. iii. The resulting store would be huge and the management of large stores is difficult. In particular allocation of free space, garbage collection, unique naming of new objects and the construction of appropriate navigation tools are all more difficult ....

Koldinger, E., Chase, J. and Eggers, S. "Architectural Support for Single Address Space Operating Systems", Architectural Support for Programming Languages and Operating Systems, Boston, Mass, pp. 175-197, 1992.

....sharing in this example requires already 100 overhead. For one special architecture, the pure single address space system, the IPT overhead can be reduced, but only for a small number of protection domains or very specialized protection models. Technical details and problems in full paper. [16, 7]) 3.5 Scalability Can we scale address spaces Are they lightweight resources which can e.g. be used for implementing small active objects Multiple address spaces can be implemented by extending the 64 bit virtual addresses by an address space number. TLB and page table walker then handle e.g. ....

....flushing the complete TLB Ongoing research [26, 22, 21, 23] deals with these questions. It is yet too early for definite answers, but we are not pessimistic. 5 Related Work 64 bit systems: Opal [4] Mungi [34, 7] Monads [33] and [2] Page table mechanisms: 31, 6, 10] TLBs and caches: [16, 15, 30, 5]. User level mapping: 1, 9] OO systems: 13, 17] 6 Conclusions Besides that we never can be sure to consider all relevant factors in such an examination, there are remarkable factors of uncertainty: research is required to find out 7 whether appropriate TLBs and caches can be build and ....

E. J. Koldinger, J. S. Chase, and S. J. Eggers. Architectural support for single address space operating systems. In 5th International Conference on Architectural Support for Programming Languages and Operating Systems, pages 175-- 186, Boston, MA, October 1992.

....to an initial APD data structure. This structure, for example, could be obtained from an RPD using a standard 4 In the common case of read only or execute only sharing of system objects, the access modes are likely to be the same. 5 A similar approach has been proposed by Koldinger et al. [12] 9 service routine, or could be specially constructed by the parent. A common case would be for the child to inherit the parent s APD. APD modifications can be performed in one of two ways. A process may, provided it holds the appropriate capabilities, modify the actual Clists pointed to by the ....

....of password capabilities called protected pointers to control access to objects. The protected pointers also contain portal numbers which are used in crossdomain procedure calls. As well, the Opal group is investigating hardware mechanisms to support the separation of translation and protection [12]. Opal also provides two methods of validating access to an object. The first is by explicitly presenting a capability to the attach system call. Attempts to access unattached objects cause a protection fault and the system then attempts to validate the access implicitly. It is not clear, ....

E. J. Koldinger, J. S. Chase, and S. J. Eggers. Architectural support for single address space operating systems. In Proceedings of the 5th InternationalConference on Architectural Support for Programming Languages and Operating Systems, pages 175--86, 1992.

.... and perhaps also for supercomputers. There are strong reasons that unlike the move from 16 to 32 bit addressing, a 64 bit address space will be revolutionary instead of evolutionary with respect to the way operating systems and applications can use virtual memory. Koldinger, Chase, Eggers [8]) Experimental single address space operating systems are for example Opal [4, 3] and Mungi [6] a similar design is described in [2] and [16] The latter system especially relies on rich per page protection facilities. One serious problem coming up in this context is sparsity. A 2 64 byte ....

E. J. Koldinger, J. S. Chase, and S. J. Eggers. Architectural support for single address space operating systems. In 5th International Conference on Architectural Support for Programming Languages and Operating Systems, pages 175--186, Boston, MA, October 1992.

.... buffer for caching capability translations, called a segment look aside buffer (SLB) CAP s capability unit contained a slave memory that held 64 evaluated capabilities [NW77] A protection look aside buffer (PLB) similar to a SLB, has also recently been suggested by Koldinger et al. KCE92] The PLB would cache the protection information while the TLB would contain only translation information. A PLB would not have to be as large as the TLB to be effective, as it can cache protection information over regions that are larger then a page, for instance a set of contiguous pages that ....

Eric J. Koldinger, Jeffrey S. Chase, and Susan J. Eggers. Architectural support for single-address-space operating systems. In Proceedings of the 5th International Conference on Architectural Support for Programming Languages and Operating Systems, pages 175--86, 1992.

....components in order to balance performance and failure isolation. Elements of the Opal research focused on programming environments for data persistence and protected sharing [8] recovery and consistency for distributed data [20] architectural issues for address translation and protection [28], and operating system abstractions and resource management [15] 2 2.2 End System Networking and Network Storage At the time that I moved to Duke, Mike Feeley and others in the Opal team were turning their attention to virtual storage models for networks. This led to a follow on project called ....

E. J. Koldinger, J. S. Chase, and S. J. Eggers. Architectural support for single address space operating systems. In Proceedings of the Fifth International Conference on Architectural Support for Programming Languages and Operating Systems, October 1992.

No context found.

Eric J. Koldinger, Jeffrey S. Chase, and Susan J. Eggers. Architectural support for singleaddress -space operating systems. In Proc. 5th ASPLOS, pages 175--86, 1992.

No context found.

Eric J. Koldinger, Jeffrey S. Chase, and Susan J. Eggers. Architectural support for singleaddress -space operating systems. In Proc. 5th ASPLOS, pages 175--86, 1992.

No context found.

Eric J. Koldinger, Jeffrey S. Chase, and Susan J. Eggers. Architectural Support for Single Address Space Operating Systems. Technical Report 92-03-10, University of Washington, July 1992.

No context found.

E. J. Koldinger, J. S. Chase, and S. J. Eggers. Architectural support for single address space operating systems. In ASPLOS, October 1992.

No context found.

Koldinger, E.J., J.S. Chase, S.J. Eggers, "Architectural Support for Single Address Space Operating Systems," Proc. 5 International Conf. On Architectural Support for Programming Languages and Operating Systems (ASPLOS V), Oct. 1992, pp. 175-186.

No context found.

E. J. Koldinger, J. S. Chase, and S. J. Eggers. Architectural support for single address space operating systems. In ASPLOS, October 1992.

No context found.

E. J. Koldinger, J. S. Chase, and S. J. Eggers. Architectural support for single address space operating systems. In ASPLOS, October 1992.

No context found.

E. J. Koldinger, J. S. Chase, and S. J. Eggers. Architectural support for single address space operating systems. In ASPLOS5, pages 175--186, Oct. 1994.

No context found.

Eric J. Koldinger, Jeffrey S. Chase, and Susan J. Eggers. Architectural support for single-address-space operating systems. In Proceedings of the 5th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), pages 175--86, 1992.

No context found.

E. J. Koldinger, J. S. Chase, and S. J. Eggers. Architectural support for single address space operating systems. In ASPLOS, October 1992.

No context found.

E. J. Koldinger, J. S. Chase, and S. J. Eggers. Architectural support for single address space operating systems. In ASPLOS-V, 1992.

No context found.

E. J. Koldinger, J. S. Chase and S. J. Eggers, `Architectural support for single address space operating systems', Proceedings of the Fifth International Conference on Architectural Support for Programming Languages and Operating Systems, Boston, Massachusetts, October 1992. SIGARCH Computer Architecture News, 20, (Special issue), 175--186 (1992).

No context found.

Koldinger, E. J., Chase, J. S. and Eggers, S. J. Architectural support for single address space operating systems. In Proceedings of the 5th International Conference on Architectural Support for Programming Languages and Operating Systems, Boston, Massachusetts, ACM, 175-186, 1992.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC