R. W. Dean and F. Armand, "Data Movement in Kernelized Systems", USENIX Workshop on Micro-kernels and Other Kernel Architectures, Seattle, WA, Apr, 1992, 243-261.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....that the dominant cost of migration in Chorus is the shipment of pages, an implementation on faster hardware would lead to a significant improvement in performance. For example, page faulting and flushing on an Intel 80386 implementation of Chorus takes about 16 milliseconds per 4 kilobyte page [9]. The total time to migrate the address space of a 100 kilobyte Chorus actor that has touched 30 percent of its address space on this system would thus be about 120 milliseconds, over 25 times faster than the MicroVax II implementation. Slightly better times could be achieved with even faster ....

Randall W. Dean and Francois Armand. Data Movement in Kernelized Systems. Technical report, Carnegie Mellon University and Chorus Syst'emes, 1992.

....Page tables may be shared whenever a new instance of an existing application is created. The effect of sharing code space in such cases significantly reduces application startup latencies. Experience with Mach and Chorus suggested that heap growth may inhibit system performance if it is slow [8, 21]. The POSIX design allows the operating system to grab any available swap page and zero it. We constructed a Linux benchmark using the lmbench timing framework, and determined that growing the heap by a page takes 31.74 s. In EROS, the fault must first be reflected to a user level fault handler ....

....[39] use capabilities for interprocess communication. Mach also uses them to name memory objects. Both use external memory managers. Neither externalizes storage allocation or provides persistence, and in both cases the external memory manager has proven to be a source of performance difficulties [21, 8]. Both systems are hybrid designs, in that other system calls are present in addition to capability invocation. While Mach originally started with a single mach msg system call, additional system calls were later added for performance. The Mach send once port bears a close resemblance to the EROS ....

R. Dean and F. Armand. Data movement in kernelized systems. In Proc. USENIX Workshop on Micro-kernels and Other Kernel Architectures, pages 243--262, Seattle, WA, USA, Apr. 1992.

....the design of a virtual memory management [ARS89, ARG89] has two different aspects: ffl an operating system needs a backing storage if a processor has to page out data because the main memory is needed for other tasks. ffl a distributed system, such as ODOS, supports distributed shared memory [AD92, AJL92] The memory pages of one address space can be distributed over several sites. The access to remote sites is handled by the virtual memory system. Memory Management Unit ODOS allows several tasks to be run together in the same memory. Therefore, it depends on runtime mapping from virtual ....

Francois Armand and Robert Dean. Data Movement in Kernelized Systems. In: Proc. of the Usenix Workshop on Micro-kernels and Other Kernel Architectures, Seattle, WA, April 27-28, 1992.

....implement the read and write system calls in the emulator by using mapped files. It would also be necessary to enhance the vnode pager to handle pageouts (writes) and consistency between pageins and pageouts and other additional state. For an analysis on data movement using a mapped interface see [12]. 4.12 Representing Files as Ports In BSD, file descriptors are managed by the kernel. In a server environment it has some drawbacks, however. If a client program has files open with several servers at once, files shared between clients, or files managed altogether by the emulator, it will be ....

Randall Dean and Francois Armand. Data Movement in Kernelized Systems. Carnegie Mellon University and CHORUS Systemes.

....application demands or new I O interfaces. Also, having the code in the application library reduces the demand on possibly contended system servers. The fast LSI facility allows us to maintain state in the OFS that we would otherwise have to cache in the application level (as is done by Mach 3. 0 [7]) This greatly simplifies our code for handling application errors and is probably also more robust. The name server allows locally accessed portions of the name space to be cached on each cluster. Finally, the portion of the file system that cannot be paged out is minimized (i.e. the BFS ....

Randall W. Dean and Francois Armand. Data Movement in Kernelized Systems. In USENIX Workshop on Micro-kernels and Other Kernel Architectures, pages 243--262, Seattle, Wa., April 1992.

....that the dominant cost of migration in Chorus is the shipment of pages, an implementation on faster hardware would lead to a significant improvement in performance. For example, page faulting and flushing on an Intel 80386 implementation of Chorus takes about 16 milliseconds per 4 kilobyte page [26]. The total time to migrate the address space of a 100 kilobyte Chorus actor that has touched 30 percent of its address space on this system would thus be about 120 milliseconds, over 25 times faster than the MicroVax II implementation. Slightly better times could be achieved with even faster ....

Randall W. Dean and Fran¸cois Armand. Data Movement in Kernelized Systems. Technical report, Carnegie Mellon University and Chorus Syst'emes, 1992.

....that the dominant cost of migration in Chorus is the shipment of pages, an implementation on faster hardware would lead to a significant improvement in performance. For example, page faulting and flushing on an Intel 80386 implementation of Chorus takes about 16 milliseconds per 4 kilobyte page [7]. The total time to migrate the address space of a 100 kilobyte Chorus actor that has touched 30 percent of its address space on this system would thus be about 120 milliseconds, over 30 times faster than the MicroVax II implementation. Slightly better times could be achieved with even faster ....

Randall W. Dean and Fran¸cois Armand. Data Movement in Kernelized Systems. Technical report, Carnegie Mellon University and Chorus Syst`emes, 1992.

....mapped into the virtual space. Many of these services, however, can be moved into separate server tasks, increasing the modularity and extensibility of the operating system [5] For this reason, numerous microkernel based operating systems have been developed in recent years (e.g. Chorus [10], Mach 3.0 [1] V [7] By migrating these services into separate user level tasks, operating systems like Mach 3.0 fundamentally change the behavior of the system for two reasons. First, moving OS services into user space requires both their program text and data structures to be mapped. ....

Dean, R.W. and F. Armand. Data movement in kernelized systems. in Micro-kernels and Other Kernel Architectures. 1991. Seattle, Washington: USENIX.

....another segment is made master. If a copy on write fault occurs on a non master segment, then the data is just copied to a private page. Chorus is a microkernel based operating system with an object oriented virtual memory interface developed in the early 1990s at Chorus Systems and INRIA, France [1, 2, 17]. The interface for the virtual memory system is called the generic memory management interface or GMI. The GMI defines a set of virtual memory operations that the Chorus microkernel supports. Each process under Chorus has virtual memory context 68 that consists of a set of mapped regions. ....

R. Dean and F. Armand. Data movement in kernelized systems. Technical Report CS-TR-92-51, Chorus Systemes, 1992.

....servers. An important difference, however, is that unlike our implementation all UNIX process calls in MiX V.4 have to pass through the PM on their way to their respective servers. In addition, the MiX V. 4 implementation is tuned for running the various MiX servers in the supervisor address space [6] (although MiX V.4 servers are fully independent and can run in independent user spaces) We do not plan on moving our servers into supervisor space. We share with MiX V.4 the support for network wide shared files and the general distributed nature of the implementation. However, we only implement ....

R. W. Dean and F. Armand, "Data Movement in Kernelized Systems", Proceedings of USENIX Workshop on Micro-kernels and Other Kernel Architectures, April 1992, pp. 243-261.

....mapped into the virtual space. Many of these services, however, can be moved into separate server tasks, increasing the modularity and extensibility of the operating system [8] For this reason, numerous microkernel based operating systems have been developed in recent years (e.g. Chorus [19], Mach 3.0 [4] V [20] By migrating these services into separate user level tasks, operating systems like Mach 3.0 fundamentally change the behavior of the system for two reasons. First, moving OS services into user space requires both their program text and data structures to be mapped. ....

Dean, R.W. and F. Armand. Data movement in kernelized systems. in Micro-kernels and Other Kernel Architectures. 1991. Seattle, Washington: USENIX.

....of system calls. For example, the OSF 1 implementation of Unix I O uses an emulation library in the application address space that maps (Section 2.2. 2) large file regions into the application address space and copies data to or from the mapped regions, hence reducing the number of system calls [30]. Accessing uncached file data Unix I O also entails large overhead when data is being transferred to or from disks. The copying between buffers (described in the previous section) increases contention on the memory. For example, researchers who have dramatically improved file I O bandwidth (by ....

....well to multicomputers, although substantial modifications to our implementation of HFS would be necessary. One open question in porting HFS to a multicomputer would be whether mapped file I O should be used. The fact that the OSF 1 file system for the Paragon multicomputer uses mapped file I O [30] suggests that it would not be a problem. However, it is not clear how the mapping facility provided by the Vesta file system [25] where an application can impose a mapping between the bytes in the file and the order that the file system will provide these bytes to the application) can be ....

R. Dean and F. Armand. Data movement in kernelized systems. In Usenix Workshop on Micro-kernels and Other Kernel Architectures, 1992.

....performance advantage of implementing stream I O with mapped files. For example, Unix I O can be implemented in the operating system using mapped files, allowing the system to exploit the virtual memory hardware to improve the search time of the file cache [BRW89] The Mach 3. 0 operating system [DA92] reflects Unix I O calls back to the application level where they are serviced using mapped files. Finally, the sfio library [KV91] uses mapped files whenever possible. On some systems, Unix I O can be more efficient than mapped file I O for some types of access (e.g. for writing past the EOF) ....

....and has called sfree. 12 Our emulated Unix I O implementation uses a per application file offset, and hence does not support the sharing semantics of Unix. Also, read and write operations are not atomic (as is the case with the system call interface) In the Mach 3. 0 operating system [DA92] Unix I O is implemented by an emulation library where the library and the file system cooperate to: 1) handle file offsets shared by multiple applications, 2) ensure that read and write operations are atomic, and 3) handle the EOF problem described above. It would be interesting to port ASF to ....

R. Dean and F. Armand. Data Movement in Kernelized Systems. In Usenix Workshop on Microkernels and Other Kernel Architectures, 1992.

No context found.

R. W. Dean and F. Armand, "Data Movement in Kernelized Systems", USENIX Workshop on Micro-kernels and Other Kernel Architectures, Seattle, WA, Apr, 1992, 243-261.

No context found.

F. Armand, R.W. Dean. Data Movement in Kernelized Systems. In Proceedings of the Usenix Workshop on Micro-kernels and Other Kernel Architectures, April 1992.

No context found.

Dean, R. W. and Armand, F. Data movement in kernelized systems. In Proceedings of the Micro-kernels and Other Kernel Architectures Workshop, Seattle, Washington, USENIX, 243-261, 1991.

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