Not an expert by any means, but I believe the brk overcommitment behaviour is a (compile or runtime) option on Linux, as well … On Jul 12, 2013 12:24 PM, "Camm Maguire" <c...@maguirefamily.org> wrote:
> Greetings! Largely to accommodate acl2's growing appetite, I've put in > some memory management enhancements in 2.6.9. Among these is a dynamic > maxpage -- no longer a compile time constant, the executable will try to > manage memory according to the amount available at runtime. > > This of course does not pertain to Windows or Mac, where sbrk is > emulated. (Don't really think sbrk needs mac emulation, but that will > have to wait.) > > I've run into a few issues with this across the available unix like > systems, no surprise. There does not appear to be a generic reliable > way to determine the available memory in advance without waiting for a > failure in the middle of some calculation. The first attempt is using > brk, which is nice as it does not actually add pages to the process > until the memory is written. Some systems, notably kfreebsd and perhaps > hurd, return success for brk calls beyond the physical memory of the > system. Next I tried supplementing with sysconf (_SC_PHYS_PAGES). This > actually returns -1 an ia64, which appears permissible from the > manpage. On the bsd's it appears to work OK. > > Suggestions? > > Take care, > -- > Camm Maguire c...@maguirefamily.org > ========================================================================== > "The earth is but one country, and mankind its citizens." -- Baha'u'llah > > _______________________________________________ > Gcl-devel mailing list > Gcl-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/gcl-devel >
_______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
