lkml.org 
[lkml]   [2000]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Overcommitable memory??
On 13 Mar 2000, Rask Ingemann Lambertsen wrote:
>
>Apps would be told that the system is out of memory instead of just
>getting a SIGKILL'ed out of the blue sky. Apps getting NULL from
>malloc() can react appropriately, such as saving your files to disk,
>trying again a little later or just exiting if that is acceptable for
>what the app was doing. Apps getting SIGKILL will take your unsaved work
>with them in the fall.

Ok, so my big gravitational simulation gets NULL from malloc and decides
to save it's work and exit. Uh-oh, time to demand-load a page of
executable code that had been discarded, so we can save the data. Hmm, but
we're out of memory...

Even if that succeeds, or there is a foolish "no overcommit" policy, we
need disk buffers. What if the program was told to save output to a SCSI
device, and the kernel needs to load the driver module? We're out of
memory! Even if we all build non-modular kernels, the kernel does some
dynamic memory allocation.

As for "trying again a little later", that leaves you with an unresponsive
and unusable system in many cases.

And please explain why my simulation -- that may have started many weeks
(or months) ago -- should "just exit" because some random 5-minute old
Mathematica process went and allocated half a gigabyte of memory?

Dave

David Whysong dwhysong@physics.ucsb.edu
Astrophysics graduate student University of California, Santa Barbara
My public PGP keys are on my web page - http://www.physics.ucsb.edu/~dwhysong
DSS PGP Key 0x903F5BD6 : FE78 91FE 4508 106F 7C88 1706 B792 6995 903F 5BD6
D-H PGP key 0x5DAB0F91 : BC33 0F36 FCCD E72C 441F 663A 72ED 7FB7 5DAB 0F91



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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