On 12 Apr, Dan Nelson wrote: > In the last episode (Apr 12), Nick Barnes said: >> This is the well-known problem with my fantasy world in which the OS >> doesn't overcommit any resources. All those programs are broken, but >> it's too costly to fix them. If overcommit had been resisted more >> effectively in the first place, those programs would have been >> written properly. > > Another issue is things like shared libraries; without overcommit you > need to reserve the file size * the number of processes mapping it, > since you can't guarantee they won't touch every COW page handed to > them. I think you can design a shlib scheme where you can map the libs > RO; not sure if you would take a performance hit or if there are other > considerations.
The data and bss sizes in most shared libraries are small, so I don't think that is much of an issue. The text pages are more of a problem because of the need to do relocation fixups. It would be nice to mark the text pages read only after relocation and/or prelink the binaries and shared libraries like recent versions of Linux do. Text page modifications to set debugger breakpoints would also have to be handled. A bigger problem is the default stack size of 64 MB per process. That quickly adds up to a lot of reserved swap space. One way of handling that might be an ELF header field that could limit the stack size to a smaller value for most binaries. I don't happen to remember the default SunOS 4.x stack size, but I suspect that SunOS 4.x overcommited stack space on the assumption that most processes wouldn't use anything close to the limit. > There's a similar problem when large processes want to > fork+exec something; for a fraction of a second you need to reserve 2x > the process's space until the exec frees it. vfork solves that > problem, at the expense of blocking the parent until the child's > process is loaded. The fork() case was a common failure mode that I ran into back when I was using SunOS 4. It was usually a fairly benign problem because the fork() was triggered by an interactive command, and when it failed I could usually recover from the problem by exiting some other process or by freeing up some swap space by removing files from the swap-backed /tmp directory. In an earlier life, I had the displeasure of trying to run large processes (~3x RAM) on a small-memory machine without either COW or vfork(). Actually, fork() was required in at least some of the cases because the process wanted to make a snapshot of itself to do processing on its in-memory data in the background. The machine would page like crazy and swap other processes in and out for about an hour each time the large process forked. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
