[lkml]   [2005]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: process creation time increases linearly with shmem
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...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-08-26 19:03    [W:0.134 / U:3.704 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site