On Wednesday 13 June 2007 06:32:42 pm Jin Guojun wrote: > Umm, the amount of physical memory has no bearing on how the virtual > address space for userland is laid out. Do you know what virtual memory > is and how it works? Your first e-mail seems to contradict this paragraph > as in your first e-mail you noted that the physical memory doesn't matter, > the solution was to not raise MAXDSIZ higher than 1GB and that is consistent > with running out of virtual address space due to MAXDSIZ reserving too much > address space for malloc(). > > No quite clear on this. Does this mean that the MAXDSIZ cannot exceeed 1GB regardless > how many physical memory (say 16 GB) is installed? Then, this is definitiely a software bug. > Then, somewhere the following checking is needed: > > #if (MAXDSIZ > 1024 * 1024 * 1024) > #undef MAXDSIZ > #define MAXDSIZ (1024 * 1024 * 1024) > #endif
It depends on the app. Some apps you can crank the malloc space up a whole lot. Also, if you are running FreeBSD/amd64 and running a 32-bit binary under freebsd32 emulation, then it has 4GB of VA space rather than 3GB, so you can give it more MAXDSIZ. It's really up to the user to only use a maxdsiz that works. You can also adjust the hard limit before exec'ing a process that needs a smaller dsize and leave MAXDSIZ larger for other processes. Since it is dependent on things the compiler can't know about at the build time of the kernel, we just let the user set it to whatever and if they set it too high things break until they lower it. You can even set this at boot time via 'kern.maxdsiz' tunable in the loader w/o needing to recompile. -- John Baldwin _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
