lkml.org 
[lkml]   [2000]   [Mar]   [15]   [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:

> 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.

Without overcommit, it just runs out of memory much earlier - even though
there is free memory available, that memory might have been used by
something else, so it isn't available to the simulation.

> > 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.

Yes - but it will almost certainly allocate some memory dynamically. It
could, for example, be saving to an automounted NFS home directory. Are
you going to keep enough RAM free to handle that at all times? How?

> > 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.

Well, your approach would completely destroy any possibility of using
Linux for WWW servers, for example. It would also increase memory wastage
enormously when every single shell spawned has to be copied individually,
instead of being COW mapped. So, instead of my 128Mb server being quite
happy with half a dozen Netscapes, bash shells, emacses etc. being open,
it collapses into a fit of disk thrashing with just a few shells and a
copy of Emacs loaded.

All your idea really does is increase memory consumption enormously, and
make memory problems much more frequent.

If you REALLY want this on your machine, try hunting for an early Linux
kernel. 1.0.x has most of the "features" you are after, I think?


James.


-
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:1.814 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site