Re: process creation time increases linearly with shmem

[Ray Fucillo <fucillo@intersystems.com>]

Nick Piggin wrote:
> OK let's see how Ray goes, and try it when 2.6.14 opens...

Working on that now - I'll let you know.

> Yeah I guess that's a good idea. Patch looks pretty good.
> Just a minor issue with the comment, it is not strictly
> just assuming the child will exec... IMO it is worthwhile
> in Ray's case even if his forked process _eventually_ ends
> up touching all the shared memory pages, it is better to
> avoid many ms of fork overhead.

Yes, in our database system the child will immediately touch some shmem 
pages, and may eventually touch most of them (and would almost never 
exec()).  Fork performance is critical in usage scenarios where an 
end-user database request forks a new server process from one master 
server process.

However, there is still a need that the child, once successfully forked, 
is operational reasonably quickly.  I suspect that Ross's idea of paging 
in everything after the first fault would not be optimal for us, because 
we'd still be talking about hundreds of ms of work done before the child 
does anything useful.  It would still be far better than the behavior we 
have today because that time would no longer be synchronous with the 
fork().  Of course, it sounds like our app might be able to make use of 
the hugetlb stuff can mitigate this problem in the future...