On 11/11/2011 08:06 PM, Tejun Heo wrote:> Hello,> > On Fri, Nov 11, 2011 at 7:58 AM, Pavel Emelyanov <xemul@parallels.com> wrote:>>> Hmm. It seems, we can make a simpler patch to achieve the (roughly)>>> same effect. Without touching copy_process/alloc_pid paths. What if>>> we simply add PR_SET_LAST_PID? (or something else).>>>>>> In this case the new init (created normally) read the pids from image>>> file and does prcrl(PR_SET_LAST_PID, pid-1) before the next fork.>>>>>> What do you think?>>>> This will make it impossible to fork() children on restore in parallel. And>> I don't want to lose this ability :(> > It's highly unlikely that the ability to fork in parallel would> contribute to any meaningful speedup. That is not the critical path by> *far* and I don't think it's worth optimizing for. Forking in serial> and restoring the rest of states in parallel should be enough.

Well, I wouldn't say that for sure, but anyway. I'm not talking here about theperformance issues only. If we accept that we fork tasks one-by-one, then thiscreates great synchronization problems.

First of all - let's imagine that we just want to clone a set of tasks. Theneach of them will have to fork its kids, then report first of them that he'sOK to fork and wait for it to report back, that forking is done. Then do thesame for the rest of them. This is not impossible, but painful.

Next - let's consider we have some tasks sharing various resources, e.g. mm-sor fd-tables. This means, that these tasks should be cloned in the carefullycalculated sequence with CLONE_XXX flags set. In this case the described abovescheme with fork() serialization simply won't work and we'll have to inventsome fancy messaging with "now X fork with Y pid" and "X done with forking,please go on" messages.