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. 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.
--
Dan Nelson
[EMAIL PROTECTED]
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
