>     If you are looking to blame overcommits for your problems, then lay out
>     how your system is setup.  But I'll bet you the problem is something 
>     less severe -- like a simple misconfiguration, or perhaps insufficient
>     swap.  How much swap is on this system, by the way?

I could just as rightfully argue that you're blaming a failure of the
OS on the sysadmin.  Fiddling with limits is all fine and dandy, but
it's not even close to flexible enough.  Consider, for example, the
specific case of testing a new multi-threaded program.  A simple
mistake caused it to chew up a rather considerable amount of memory --
the per-process limit for each of 32 processes.  You could claim
several things here:

* I should have tested it on another system.  That's great, but at $Nm
  per system, that's often infeasible.

  Not only that, but it's insulting.  Why should I have to buy two
  computers, just because the OS can't be bothered to properly protect
  my important programs?

* I should have allocated enough swap space to cover this situation.
  That's great, but if I did, using a no-overcommit policy would have
  worked just as well!

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.