After a process migrates, the first message sent to it by a remote process causes an update sent back to the sender informing it of the mirgrated process's new location.But how does the system implement it?
For simplicity, say originally, process P1 is in machine A, process P2 is in machine B. P2 has a link pointing to P1. My thoughts are: when P1 migrates,
1. P1 sends a message to SwitchBoard to update its link and leaves a clue in Machine A's link table which says it has migrated, then when P2 send message m to P1's old link, it finds out the clue and consults the SwitchBoard where to be forward. Of course, forward address can also be field in link table (which eliminates the need of consulting SwitchBoard).
But will it be a memory overhead since most processes does not migrate? And how should the message m be forward, by machine A or first sent back to machine B and resent by machine B? And if P1 migrates several times, the message m must be transfer multiple times in order to get to P1, and that will be intolerable if P1 is accessed heavily.
2. P1 simply sends a message to SwitchBoard and SwitchBoard broadcasts this change. But there are two problems, SwitchBoard does not know the full list of processes which have links to P1; might cause a big flow of messages and lose the "copy-on-write" like property.
So, how it's actually done? The paper seems to focus on the general communication method and does not talk much about the details.
Turns out there is a whole paper dedicated to "Process Migration in DEMOS/MP". Here is the link: http://www.eecs.berkeley.edu/Pubs/TechRpts/1983/6350.html
ReplyDeleteLet me give a short version of how links are updated:
1. Whenever a process migrates, a degenerate process is left behind on the source machine. The only remaining process state associated with this degenerate process is the "forwarding address". The "forwarding address" is the address of destination machine that it moved to.
2. DEMOS/MP has a message forwarding mechanism. This enables a kernel to modify and forward message to a kernel on some other machine. This was essential to take care of the messages that were in-transit or in the process's message queue when the migration began. Now, for messages received on old links the same kernel-to-kernel forwarding mechanism can be used as long as the degenerate process exists. However, routing messages through an intermediate machine reduces message performance and defeats the purpose of process migration.
3. So, DEMOS/MP used a lazy mechanism for updating links. Old links are updated as they are used. Whenever a message is received on an old link, it is forwarded using the forwarding mechanism, at the same time the forwarding machine also sends a special message to the kernel of the process that sent this message. As the paper describes: "This special message contains the process identifier of the sender of the message, the process identifier of the intended receiver (the migrated process), and the new location of the receiver. All links in the sending process's link table that point to the migrated process are then updated to point to the new location."
Thanks! Very helpful link and summary!
Delete