>The point is, the OS should have provided *some* mechanism to insure >that the long-running process wasn't affected. It didn't. That's a >clear failure of the OS to provide a reasonable environment for this >type of computing. > >Whether this should be solved by switching to a no-overcommit policy, >fiddling with the overcommit policy in some way, or whatever, is a >different issue. But you have not yet proposed any mechanism that >would have prevented this problem while still permitting me to get >work done.
I've long felt that the best solution to problems like this is a per-user swap space quota. This gives admins a knob to manage the allocation of swap space while still allowing overcommit. The downside is that it doesn't provide a graceful way for a program to recover from it's overconsumption sins. I'd argue, however, that buggy software or incorrectly tuned systems should get what they deserve. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
