lkml.org 
[lkml]   [1997]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Memory overcommitting (was Re: http://www.redhat.com/redhat/)
-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 19 Feb 1997, John Wyszynski wrote:

>
> SUICIDE! No wonder Linux gets such a rap for being unreliable. (If this is
> truely how things work. Someone please tell me this isn't so.)
> As a programmer I expect that when I have sucessfully requested memory to
> be allocated, that it really has happened. It now appears that on top of
> everything else that writing to memory at the wrong time, I could run of
> virtual memory.

This is ridiculous! Of *course* you could run out of virtual memory. You
could install 512 MB and still run out of virtual memory if you ran enough
processes. If it wasn't for optimistic allocation, you would run out of
VM *MUCH* faster.

Optimistic allocation has proven to work quite well. It's mere
statistics. Processes often overallocate, it's a fact of life.
Experience has shown that that allowing overallocation causes NO problems,
and the payoff is tremendous. Think about it for a minute, even if your
allocations aren't committed, you aren't going to have a problem using
that memory until nearly ALL the VM on the system has been used. If all
the VM is in use, the overall system performance will have _dramatically_
decreased and it will be painfully obvious (massive swapping) that you are
in trouble. You seem to be intimating that suddenly all available VM will
"disappear" and you'll segfault. That simply isn't going to happen.

+-------------------------------------------------------------------+
+ -- Finger: flood@evcom.net for my PGP public key -- +
+-------------------------------------------------------------------+

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMwue5xsjWkWelde9AQE9cAQAr9ftF097VmaBd+aWPHlttOqbHw+dmENL
CljU2J98K8bqlS2xFsBe+0632ujRPM7eSWHypCI/1tzCxXQUuqVU/aiF4OT6A4QT
iUsHNc/5K20cvYViqOe+XrQui1oh16mwng9WUBN7quB8EX3g7Km+vWuQiJvpZdnF
CzptYp16qW4=
=YKL1
-----END PGP SIGNATURE-----


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.096 / U:0.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site