Re: [PLUG] Swap on SD

[Edmond Rodriguez <erodrig_97@yahoo.com>]

I guess that overcommit_memory file does not need a reboot when it is changed since I think it gets reset back to 0 after a reboot. 

I ran a test loop of malloc in a C program and was able to allocate 3GB (in accumulated pieces of size 102400) of memory on my machine with only 1.3 GB or RAM (with swap off).   If I write to the memory after allocating it, things seem more as expected, it dies at 1GB.  If I do not write to the memory I have allocated, the command "free" will only show that I have used an additional 4 MB, even though I allocated 10MB.  If I write data to all that allocated memory, the command free will show all 10MB used. 

So it looks like my program can be fooled into getting 3GB of memory when only 1GB is available. 

The value of 2 in /proc/sys/vm/overcommit_memory does not seem to remedy the ability to get more memory than I have availabe on my 2.6.27.7-smp kernel.




----- Original Message ----
> From: Ben Love <blove+plug@kylimar.com>
> To: Philadelphia Linux User's Group Discussion List <plug@lists.phillylinux.org>
> Sent: Wednesday, August 19, 2009 3:12:44 PM
> Subject: Re: [PLUG] Swap on SD
> 
> * Richard Freeman (r-plug@thefreemanclan.net) wrote:
> > Linux has a routine called the out-of-memory killer that takes case of
> > this.  The name does a good job of implying how it works.  Processes are
> > killed and their memory is freed.  The algorithm attempts to get the
> > most space from the fewest killed processes, with some emphasis on
> > trying to find ones the user won't mind losing too much.
> 
> The particular setting in question here is
> /proc/sys/vm/overcommit_memory.  The question is, does Linux grant your
> process more memory than it requests?
> 
> The kernel default is 0, which means to heuristically overcommit.  (Your
> distribution might choose a different default though.)  Some checking of
> available memory is done, but it's not guaranteed.  In particular, some
> mmap() requests may pass MAP_NORESERVE, which disables the check.
> Overall, there is some risk of the OOM killer.
> 
> A value of 1 means that /every/ request for memory is granted (malloc()
> never returns NULL).  This can quickly lead to the OOM killer; "caveat
> processtor!" (Let the process beware!)
> 
> A value of 2 (only since 2.6) and means the kernel should never allocate
> memory it doesn't have (swap space included).  In this way, malloc()
> would return NULL, and in theory the OOM killer would never have to run.
> Your application does have error checking and can gracefully handle that
> case, right?
> 
> This information can be found in the man page for proc(5).
> -- 
> Ben Love
> blove+signature (at) kylimar.com  ||  ASCII ribbon campaign - ()
> http://www.kylimar.com/           ||   against HTML e-mail  - /\
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug