Re: [PATCH 3/3] pids: Make it possible to clone tasks with given pids

[Pavel Emelyanov <xemul@parallels.com>]

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 the
performance issues only. If we accept that we fork tasks one-by-one, then this
creates great synchronization problems.

First of all - let's imagine that we just want to clone a set of tasks. Then
each of them will have to fork its kids, then report first of them that he's
OK to fork and wait for it to report back, that forking is done. Then do the
same 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-s
or fd-tables. This means, that these tasks should be cloned in the carefully
calculated sequence with CLONE_XXX flags set. In this case the described above
scheme with fork() serialization simply won't work and we'll have to invent
some fancy messaging with "now X fork with Y pid" and "X done with forking,
please go on" messages.

> Thanks.
>