On Sat, Nov 18, 2006 at 05:28:46PM -0800, Richard Troy wrote:
>On linux you can use the sysctl utility to muck with vm.overcommit_memory;
>You can disable the "feature."
Be aware that there's are "reasons" the "feature" exists before you
"cast" "aspersions" and "quote marks" all over the place, and the
"reasons" are "things" like "shared memory" and "copy on write"
memory, which are "generally" condsidered "good things".
At one point someone complained about the ability to configure, e.g.,
IRIX to allow memory overcommit. I worked on some large IRIX
installations where full memory accounting would have required on the
order of 100s of gigabytes of swap, due to large shared memory
allocations. If the swap had been configured rather than allowing
overcommit, sure it might have reduced the chance of an application
allocating memory that it couldn't use. In practice, if you're 100s of
gigs into swap the system isn't going to be useable anyway.
>itself any memory. Frankly, if it takes a complete kernel rewrite to fix
>the problem that the damned operating system can't manage its own needs,
>then the kernel needs to be rewritten! </soapbox>
>
>These kernel hackers could learn something from VAX/VMS.
Like how to make a slower system? You can configure a VM to operate
the way they did 25 years ago, but in general people have preferred to
get better performance (*much* better performance) instead. It could be
that they're all idiots, or it could be that in practice the problem
isn't as bad as you make it out to be. (Maybe other people are just
better at configuring their memory usage?)
Mike Stone