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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |