Task Migration
The general steps involved in task migration are:
Task state:
Along with task transfer, its state should also be transferred to remote machine. The task state consists of register contents, stack contents, virtual address space, list of files and IO (Input/output) buffers. In addition to this, references make to child processes current working directory are also maintained by kernel as task state. A task issuspended or frozen at some point before transfer, so that its state doesnot changes furthur and then the task is transferred.
Unfreezed:
The task is executed on new machine and then put in the ready queue so that it can continue its execution.
Issues in Task Migration:
1. State Transfer:
Two main issues in state transfer are:
Issue 1: The cost to support remote task execution includes delay in freezing the task, collecting and transferring the state and then unfreezing the task. Due to lengthy delays, there might be aborting of few tasks, interacting with this task due to time out, so it is necessary that such delay should be as little as possible.
Issue 2: There can also be residual dependencies which refers to the amount of resources dedicated by previous hosts to its migrated task in order to service the request issued by migrated task. Some of the examples where residual dependencies is required are:
An implementation that requires the host to redirect the messages meant for migrated task. Location dependent system calls issued by migrated task and these calls are to be forwarded to the host where the task was originated. Residual dependency affect the reliability performance and complexity of the system. It reduces the reliability since if one of the previous host from where the task was migrated fails then the task progress can't occur. Residual dependency also reduces the availability of a host by putting the extra load due to the remote operations, initiated by migrated task. It also complicates the system operation by tranferring the task state to multiple modes.
2. Location Transparency:
A distributed system, where task migration occurs, the location transparency must be supported that is the task migration should hide the location of task. There should not be any special provision in the program for remote task execution. Location Transparency in principle requires taht task name should be independent of host name. There should also be Location Transparency to the rest of the system taht is if any operation or communication can take place without task transfer then it should also occur after the task is transferred. The mapping of names to the physical addresses can be handled in two ways:
Way 1: Addresses are stored as hints if accesses fails then by multitasking a query or by other means, the address is updated. This approach puts no hinderance to task migration as the task tarnsfer would simply result in the updation of address.
Way 2: If an object is accessed using pointers then by updating the pointer, it is possible to refer to task at new location. The pointer updation, carried out in the kernel is relatively easy as compared to the pointer updation handled by task address space.
3. Structure/ Organisation:
One of the main issue in task migration facility is to decide whether to separate policy making modules for migration mechanism (collecting, transferring and then reinitiating the state of migrating task). By separating the two, developers can easily test, different policies without affecting the migration mechanism and vice versa. Another issue is to decide where policy making modules and migration mechanism should reside normally the migration mechanism are stored in kernel. If policy making modules requires a lot of state information from kernel and if they causes minimum system overhead by interacting with kernel then policy making modules can be implemented as separate utility processes.
Like it on Facebook, Tweet it or share this article on other bookmarking websites.