| Ben Love on 19 Aug 2009 12:12:52 -0700 |
|
* 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 - /\ Attachment:
signature.asc ___________________________________________________________________________ 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
|
|