| D. Milojicic, W. Zint, A. Dangel and P. Giese, "Task Migration on the Top of the Mach Microkernel", in Proc. MACH III Symposium. Sante Fe, NM, USENIX, pp. 273-289, 1993. |
....in MOSIX [15] and RHODOS [34] Failing that, a microkernel system offers the advantage of reduced kernel state and, often, network transparency. Even so, difficulties remain none of the three microkernel implementations of which we are aware are completely satisfactory. The Mach implementation [17], like ours, aborts threads in kernel state and in addition leaves residual dependencies on the source host when migrating a Unix process. The implementation for Chorus [16] deals with system calls by waiting for them to complete. In the case of Amoeba, we believe a complete implementation is ....
D. Milojicic, W. Zint, A. Dangel and P. Giese, "Task Migration on the Top of the Mach Microkernel", in Proc. MACH III Symposium. Sante Fe, NM, USENIX, pp. 273-289, 1993.
....Mpeg Stream. Decoded Mpeg Stream. Base Station Mpeg Decoder Module. Low Bandwidth Environment. WalkStation. Decoded Mpeg Stream. Base Station Mpeg Decoder Module. Frame Buffer. Frame Buffer. Figure 1: A Migrating Video Player. support migration. Existing application migration schemes [11, 23, 17, 5, 21, 12] have not fully addressed the issues of performance, heterogeneity, dependencies on the original host, and portability. Implementations usually migrate large amounts of code and data, and require the source and target machines to be of the same processor type and operating system architecture. 2 ....
D. Milojicic, W. Zint, A. Dangel, and P. Giese. Task migration on top of the Mach microkernel. In Poceedings of the 3rd USENIX Mach Symposium. , Santa Fe, U.S.A, April 1993.
....around the cluster and to provide transparency to access at the same time. Traditional operating systems, such as UNIX, are not designed with the SSI concept in mind, extending them requires substantial skill and expensive software effort. Contemporary message passing kernels such as Mach [7] and Amoeba [34] are proved to be a more viable choice because the most critical task one has to implement is to extend the message passing mechanism to function across machine boundaries transparently, and the result will imply a cross machine SSI. 2.2.3 Middle ware Level Middle ware includes ....
....works selected here are the landmark cases in each of the categories. 3.2 Micro kernel Augmentation In this approach, the micro kernel is extended to support load distribution by migrating tasks across the network. Task is the unit of program execution in contemporary micro kernels like the Mach [7]. Task migration on the Mach micro kernel is the leading example in this approach. The micro kernel approach is believed to be the most convenient to support transparent migration because in a micro kernel, only the basic abstractions are supported within, and other functionality is provided in ....
[Article contains additional citation context not shown here]
D.S. Milojicic et al., `Task Migration on Top of the Mach Microkernel', In 3rd USENIX Mach Symposium, pp. 273-289, Santa Fe, Apr 1993.
....(2) an application typically internalizes several operating system handles (such as socket identifiers and IP addresses) which stop being relevant upon migration. Existing approaches deal with the above problems either by relying on extensive modifications to OS structures to support migration [6, 12, 13, 10], or by requiring the use of a new application programming interface (API) 2, 4, 3, 7] whose implementation isolates the application from the consequences of migration. Neither of these choices is ideal because they cannot be applied to existing OSes and applications. Moreover, most such ....
Milojicic, D., Zint, W., Dangel, A., and Giese, P. Task migration on the top of the mach microkernel. In Proc. of the 3rd USENIX Mach Symp., pages 273--289, 1993.
....terminal, whilst maintaining all terminal traffic is not lost. 5.3 Mach Mach is a message passing based distributed operating system that utilises a microker 12 nel. In Mach, the unit of execution is called a task, where each task can have multiple threads of execution. The work presented in [Milojicic et al. 93] and [Milojicic 94a] detail Mach s task migration facility. The task migration facility for Mach relies on Mach NORMA (NO Remote Memory Access) NORMA provides transparent network IPC, distributed shared memory and a distributed capability space. In Mach, the task migration facility has been ....
D. Milojicic, W. Zint, A. Dangel, and P. Giese. Task Migration on the top of the Mach Microkernel. Proceedings of the third USENIX Mach Symposium, April.
....PVM based applications. With respect to the checkpoint migration facility, two operation levels are distinguished: operating system level and user level. In operating system level implementations the resource management facilities are supported by the OS kernel. Examples of such systems are Mach [9], V Kernel [14] Sprite [5] and Charlotte [2] User level designs and implementations of adaptive systems include dynamic resource management facilities by providing their own dynamic load balancing run time support. Examples of user level designs are Condor [8] for sequential, and MPVM [3] for ....
D. S. Milojicic, W. Zint, A. Dangel, and P. Giese. Task migration on the top of the Mach microkernel. In MACH III Symposium Proceedings, pages 19--21, Santa Fe, New Mexico, Apr. 1993.
....memory as one global virtual memory. Mess provides universal and transparent access to all resources, including processors. The presence of multiple processors and a network is invisible to applications. Process migration occurs as a byproduct of the unified Distributed Virtual Memory (DVM) Mach [MZDG93] MGZ93] also uses DVM for address space transfers. Malkawi et al. studied load balancing in a simulation that models process migration as a process control transfer followed by memory transfer based on DVM [MA93] The Mess publication [DEGM90] does not make clear the Mess implementation status. ....
....here reply. Normal message recovery eventually updates the address of the migrating process and correctly delivers the messages affected by the process migration. 3.3.17 Mach Mach [ABB 86] is a message based operating system. Milojicic et al. have implemented dynamic task migration on Mach [MZDG93] MGZ93] Their task migration operates at the Mach level, and is independent of the operating system emulations, such as Unix or VMS. Their task migration is even independent of Mach applications. This raises the question of whether it is appropriate to migrate Mach level tasks without migrating ....
[Article contains additional citation context not shown here]
Milojicic, Zint, Dangel, and Giese. Task migration on top of the Mach microkernel. In USENIX Mach III Symposium, pages 273--289, 1993.
....Nest [Ezz86] Rhodos [ZGG90] Sprite [OCD 88] Syst eme V [Che88] mais une mise en oeuvre efficace est rarement obtenue. L impl ementation d un tel m ecanisme est moins complexe dans un syst eme con cu suivant la technologie micro noyau (Mach [ABB 86] Chorus [Roz92] CTCH94] MZDG93] que dans les syst emes monolithiques (UNIX, AK88] Une revue des diff erentes implantations peut etre trouv ee dans [JV89] Smi88] Une comparaison des performances des diff erentes impl ementations est difficile puisque chacune utilise un support mat eriel et des benchmarks diff erents. ....
D. S. Milojicic, W. Zint, A. Dangel, and P. Giese. Task migration on the top of the Mach microkernel. In USENIX Association Mach III Symp., Santa Fe, pages 273--289, 1993.
....the workstation OS) The Schizo server receives this exception and migrates those tasks to some other node before replying to the exception, thereby allowing the microkernel node in question to actually shutdown. The task migration mechanism used is one developed at the University of Kaiserslautern[9], which provides both eager and lazy memory object copying. When the migration is the result of a node shutdown, lazy copying is usually fatal, as the node goes down before the memory object can be faulted to the new node. Orderly shutdowns are one situation in which task migration must occur, but ....
D. Milojicic, W. Zint, A. Dangel, and P. Giese. Task migration on top of the Mach microkernel. In Proceedings of the Third Usenix Mach Symposium, 1993. Submitted.
....local LIM to obtain host information and load information of any host in the network. From Mach kernel support, the LIM provides two types of load information: load average and Mach factor. It can be easily extended to include IPC and VM activities [12] to reflect other system load information [17, 18] as well. The LIM also accepts artificial load increase [5] requests from the DM, such that the risk of having too many hosts deciding to transfer their tasks to one particular lightly loaded host at the same time is minimized. Making use of the acceptance policy supported by the DSF (to be ....
....code in the DM will be interrupted with the DSF message handler mechanism to be described in Section 3.3. 3. 2 Movement Module The Movement Module (MM) provides mechanisms for task relocation, such as transfer of tasks which have not yet begun execution, or possibly migration of tasks in execution [17, 18]. MM is designed in such a way that the DM in any host can instruct the local MM to move tasks from any host to another host. An instance of the MM needs to be present in every host participating in load distribution. The MM at the recipient site in a task movement sequence does not make decision ....
D. S. Milojicic, W. Zint, A. Dangel, and P. Giese. "Task Migration on the Top of the Mach Microkernel". In Proceedings of the USENIX Mach III Symposium, pages 273--289, Berkeley CA USA, 1993.
....in [20] by the use of a preprocessor that annotates the application with the necessary statement labels and goto calls. Aside from these software systems, support for adaptive execution on a shared environment is also available from systems such as Sprite [21, 22] Mosix [23, 24] V [25] Mach [26] and Chorus [27] The difference between these systems from MMPVM and those mentioned previously is that these systems are implemented at the operating system level. While these systems can handle most of the problems associated with user level implementations (e.g. total migration transparency ....
Dejan S. Milojicic, Wolfgang Zint, Andreas Dangel, and Peter Giese. Task migration on the top of the Mach microkernel. In MACH III Symposium Proceedings, pages 273--289, Santa Fe, New Mexico, April19--21 1993.
....systems Runtime System Time to migrate 100K unit (mSecs) Sprite SPARCStation1 330.0 Mach OMS 33MHz Intel 80486 250.0 Choices SPARCStation2 14.0 GATE SPARCStation4 22.05 Each migration system uses a different migration algorithm: Sprite [5] uses the File Server algorithm . Mach [6] uses the Demand Page algorithm . Choices [4] uses the Freeze Free algorithm . GATE uses the Total Copy algorithm. GATE implements a total copy algorithm. As the name suggests, the algorithm totally copies the task and its environment before execution is resumed. The other systems use various ....
D. S. Milojicic et. al., Task migration on the top of the Mach microkernel, Proceedings of the 3 rd USENIX Mach Symposium, Sante Fe, April 1993, pp. 273-289.
....can be broadly categorized as either supported at the system level or at the user level. In system level supported implementations, the OS kernel is involved in the migration. Notable examples of such implementation are present in Charlotte [9] V [10] Mosix [11, 12] Sprite [13, 14] and Mach [15]. User level supported process migration implementations, on the other hand, do not require services other than what the OS ordinarily provides through its system call interface. Condor [4, 6, 16] is an example of such an implementation. MPVM fits into this category. Most of the literature on ....
D. S. Milojicic, W. Zint, A. Dangel, and P. Giese. "Task migration on the top of the Mach microkernel." In MACH III Symposium Proceedings, pages 273--289, Santa Fe, New Mexico, April 19-21 1993.
....work on systematically exportable (and importable) kernel state. There is indirect evidence that not having systematically exportable kernel state makes checkpointing difficult. When others implemented support for task migration (which also needs to acquire relevant kernel state) on Mach 3. 0 [10] to migrate a thread they effectively cleared all kernel thread state with a thread abort( so that when the a new thread is created it has equivalent kernel state (none) Since thread abort( is not a transparent operation, but can impact IPC state, the Mach 3.0 task migration is not guaranteed ....
D. S. Milojicic, W. Zint, A. Dangel, and P. Giese. Task migration on the top of the Mach microkernel. In Proc. of the Third USENIX Mach Symposium, pages 273--289, Santa Fe, NM, Apr. 1993.
.... in [18] which is a generalization of Chandy and Lamport s well known algorithm [2] However the difficulty lies not so much in guaranteeing consistency as in saving and restoring the application s local states (at each site) The problem is that the local states may include complex kernel state [17, 21], such as the fact that a given thread is blocked in an RPC transaction. We are currently investigating ways to solve this problem by combining the restoration of a local state without kernel state and the re execution of the events leading to the recorded kernel state. 3 Architecture of CDB CDB ....
D. S. Milojicic, W. Zint, A. Dangel, and P. Giese. Task migration on the top of the mach microkernel. In Mach III Symposium, pages 273--289. Usenix association, 1993. Public/Approved-9- July 22, Chorus syst`emes A Distributed Execution Replay for CHORUS CS/TR-94-62
....11 account when migrating tasks. A number of tasks were started on a task migration testbed. A sender initiated distributed scheduling algorithm was activated in two versions, one that considered IPC in making decisions and another that did not. More details on this experiment can be found in [53]. This experiment demonstrates that in some cases load distribution decisions could be improved by using information about the network IPC. The performance improvement is driven by two factors. The obvious advantage comes from the fact that moving a client towards the server improves the average ....
D. Milojicic, W. Zint, A. Dangel, P. Giese, "Task Migration on the top of the Mach Microkernel, " Proceedings of the USENIX Mach Symposium, pp 273-290, Santa Fe, USA, April 1993.
....and Locator) but also in the sandbox, AC, and agent place interfaces. Similar applies to resource management. The AC and sandbox components were shaped to enable resource tracking. It would have been hard to add this support as an afterthought. Our earlier experience with Mach task migration [23] indicates that to a certain extent it is possible to add resource management or to make communication modifications as an afterthought, however, any significant support needs to be well elaborated in advance. 4.4 Naming and Locating The following objects are named in a MOA system: agent ....
....of information of agent location. The location of the home agent environment is implicitly known from the agent s name. When locating agents, different location schemes are used, similarly to those used in distributed operating systems, such as Charlotte [3] V kernel [31] Sprite [12] and Mach [23]. The MOA system supports: a) updating the home after agent moves, b) registering at a predefined name server, c) searching based on predefined itinerary and d) forwarding based on the trails left after migration (see Figure 9) Locating scheme is selected subject to: destinations (a local or a ....
[Article contains additional citation context not shown here]
Milojicic, D., Zint, W., Dangel, A., Giese, P., "Task Migration on the top of the Mach Microkernel", Proc. of the third USENIX Mach Symposium, April 1993, pp 273290, Santa Fe, New Mexico.
....task creation and migration, as well as for improved caching. As discussed earlier in the paper, this implementation suffers from severe performance problems that motivated our work. Milojicic et al. supported task migration in user space by providing copy on reference through a user level pager [6]. Although we are of the opinion that moving functionality into the user space is better architecturally, the existing Mach VM prevented us from doing so efficiently. The kernel is currently the best (and only) source of knowledge about pages; hence it is the appropriate place to start the address ....
Milojicic, D., Zint, W., Dangel, A., Giese, P., "Task Migration on the top of the Mach Microkernel", Proceedings of the third USENIX Mach Symposium, pp 273-290, Santa Fe, New Mexico, April 1993.
....and Locator) but also in the sandbox, AC, and agent place interfaces. The case is similar for resource management. The AC and sandbox components were shaped to enable resource tracking. It would have been hard to add this support as an afterthought. Our earlier experience with Mach task migration [27] indicates that to a certain extent it is possible to add resource management or to make communication modifications as an afterthought, however, any significant support needs to be well elaborated in advance. 4.4 Naming and Locating The following objects are named in a MOA system: agent ....
....of information of agent location. The location of the home agent environment is implicitly known from the agent s name. When locating agents, different location schemes are used, similarly to those used in distributed operating systems, such as Charlotte [4] V kernel [38] Sprite [12] and Mach [27]. The MOA system supports: a) updating the home after an agent moves, b) registering at a predefined name server, c) searching based on predefined itinerary and d) forwarding based on the trails left after migration (see Figure 9) The locating scheme is selected subject to: destinations (a ....
[Article contains additional citation context not shown here]
Milojicic, D., Zint, W., Dangel, A., Giese, P., "Task Migration on the top of the Mach Microkernel", Proc. of the third USENIX Mach Symposium, April 1993, pp 273-290, Santa Fe, New Mexico.
....activity must be cleanly interrupted at a restartable point of execution. This Old Wine in New Bottles June 4, 1997 3 state can either be transferred to another node in a distributed operating system, such as in MOSIX [7] or exported into the user space and then transferred, as in case of Mach [12]. The latter is required as processes can not transfer any internal operating system state between nodes. Process data transfer. A process has several types of data, such as bss, stack or memory mapped files. After migration, the operating system can transparently page in this data to its current ....
Milojicic, D., Zint, W., Dangel, A., and Giese, P. "Task Migration on the top of the Mach Microkernel", Proceedings of the third USENIX Mach Symposium, pp. 273-- 290, Apr. 1993.
....various registers, it must cleanly interrupt any operating system activity at a restartable point of execution. This state can either be transferred to another node in a distributed operating system, such as in MOSIX [7] or exported into the user space and then transferred, as in case of Mach [12]. This is required as processes can not transfer any internal operating system state between nodes. File Systems. In many cases, process migration is supported by the underlying file system (e.g. Sprite [28] This support consists of transparently moving the open connections for files and other ....
Milojicic, D., Zint, W., Dangel, A., and Giese, P. "Task Migration on the top of the Mach Microkernel", Proceedings of the third USENIX Mach Symposium, pp. 273-- 290, Apr. 1993.
No context found.
D.S. Milojicic, W. Zint, A. Dangel, and P. Giese. "Task migration on the top of the Mach microkernel." USENIX Mach III Symposium, pp. 273--289 (Santa Fe, NM, April 19--21, 1993). Berkley, CA: USENIX Association, 1993.
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