lkml.org 
[lkml]   [2000]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Overcommitable memory??

> > To make a functioning machine with absolutely NO overcommit would probably
> > require gigabytes of swap which would never be used, just to back the
> > stack pages and COW pages of all the processes. Plus, there's no real
> > gain to be had.
>
> Sure there is. 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.

The way I see it, apps that have successfully allocated memory in the past
wouldn't start dying since there's no malloc() to fail, wheras new apps
that want to bring down the system will start getting failed
malloc()/mmap()'s

There's no reason to tell an application that it has X megs of memory all
to itself to play with, and then KILL one of it's brothers if the kernel
finds itself short.

Although I do admit to the problems: It'd be impossible to log into a
system being "attacked" like that since any new login attempts would fail.

But on the other hand, malloc() DOES return EAGAIN. Some applications
would think to retry malloc() in a few seconds, which may have hopes of
succeeding.

-MB


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