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 
>  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 

John Baldwin
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to