yeah, so historically i think some late 2.2.x kernels (last time i cared about this behavior) behaved more like the "always overcommit" option, while solaris ( around 2.7 vintage ) is closer to the "don't overcommit" option.
On Fri, 11 Sep 2009, Robert Brockway wrote: > On Fri, 11 Sep 2009, Lamont Granquist wrote: > >> historically it used to be the case that to make use of any swap you >> needed more swap than available RAM, and 2xRAM used to be the practice. > > Hi Lamont. Some swap algorithms actually wouldn't work properly unless > swap was at least double ram. No modern OS should act that way through. > >> then with virtual addressing of swap that became 1xRAM. with solaris i >> believe that you still want to have some swap since it will OOM earlier if >> it doesn't have any swap (its been years since i went through the details >> of this and don't know if solaris 10 still goes OOM at the same >> threshold). linux is extremely lazy, however, so it runs fine swapless. >> >> ( i belive the difference is that if you attempt to malloc some massive >> amount of memory on solaris it will want to allocate some anon memory or >> swap space even for the anon pages that aren't being used -- and when used >> + allocated anon memory exceeds RAM + swap that solaris will OOM -- linux >> is lazy and will just OOM once it actually can't get any pages ). > > It sounds like you're talking about memory overcommit. The behaviour of > Linux is configurable but the default on modern systems is to do heuristic > checking. > > http://www.linuxinsight.com/proc_sys_vm_overcommit_memory.html > > Cheers, > > Rob > > -- > I tried to change the world but they had a no-return policy > http://www.practicalsysadmin.com > _______________________________________________ > Discuss mailing list > [email protected] > http://lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ > _______________________________________________ Discuss mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
