Den 13-Mar-00 12:54:31 skrev David Whysong fĝlgende om "Re: 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...
Without overcommit that just can not happen. There will be either a free
page of memory or a free page of swap into which you can swap something
else out.
> 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!
This is purely an administrative/user problem, not a kernel issue. Try
as you might, you will never make a foolproof system. It is also somewhat
of a hypothetical example, isn't it? Normally the module would be locked
into memory because the file system would keep it open.
> Even if we all build non-modular kernels, the kernel does some
> dynamic memory allocation.
I do not know enough about the kernel to answer that one.
> 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?
You missed the part where I wrote "react appropriately". What is
appropriate depends on which function the application has. Notice that
_with_ overcommitment of memory, your simulation that started weeks/months
ago will be "just killed" because the Matematica process needed half a
gigabyte of memory. The difference being that with overcommitment of
memory, you lose all that work. Without overcomitment of memory, you can
just restart the simulation from the files that were saved.
Please realize that the only gain from overcomitting memory is that yoy
may get away with having less swap space. The downside you get is random
program crashes, lost work, etc.
Regards,
/ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\
| Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.dtu.dk |
| Please do NOT Cc: to me or the | WWW: http://www.gbar.dtu.dk/~c948374/ |
| mailing list. I am on the list.| "ThrustMe" on XPilot, ARCnet and IRC |
| Linux is like a wigwam - no windows, no gates, apache inside! |
-
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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:24 EST