| Ben Love on 24 Aug 2009 12:05:21 -0700 |
|
* Edmond Rodriguez (erodrig_97@yahoo.com) wrote: > 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. Yes. This would make sense. Actually I was under the impression that most things in /proc/sys reset to their defaults on boot. > I ran a test loop of malloc in a C program and was able to allocate [snip] Don't forget that by calling malloc() you are probably using the standard C library, not the direct system call. Kernel documentation would only refer to the system calls. stdlib might not do quite what you expect when requesting or releasing memory. In particular, I'm pretty sure that you can only request memory from the kernel in whole pages, whereas malloc() appears to grant you only want you request. (And don't forget about byte-alignment!) I believe this is one of the major reasons that malloc() and free() are not reentrant. And of course, you're free to replace malloc() and free() with your own implementation (such as when using something like valgrind). > 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. Ok. I have to admit I didn't really expect anyone to try it out, so I didn't give all the detail from the man page. There's a second setting, /proc/sys/vm/overcommit_ratio, which determines how much/little overcommitting to do when the value is 2. In particular, it looks like the function for total address space is something like (swap + ram*(ratio/100)). On my system, it appears that 50 is the default. If yours is anything less than 100, I wonder if the function is not quite accurate. Why would you only ever want to use half of your RAM? I must be misunderstanding something here; otherwise I would expect the ratio term to be (1+ratio/100). There also seems to be a /proc/sys/vm/panic_on_oom (since 2.6.18), which is normally 0. When 1, it usually panics, but there are some special cases. When 2, you can be sure you'll know if the system ran out of memory! (Not very graceful though is it? But at least it's deterministic.) -- 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
|
|