[email protected] ("John D. Baker") writes: >Just how are the hard limit values for 'ulimit' (particularly data size, >"-d") calculated? Are there any machine-dependencies that affect this >calculation?
The data size limit is bounded by the arch dependent value MAXDSIZ defined in machine/vmparam.h. That seems to be the only limit, I don't think memory or swap size have an effect on the data size limit. Of course memory+swap put a limit on how much memory you can actually allocate even before reaching the data size limit. >What I've observed on i386, amd64 and sparc is that the hard limit is >approximately RAM+swap. i386 #define MAXDSIZ (3U*1024*1024*1024) /* max data size */ amd64 #define MAXDSIZ (8L*1024*1024*1024) /* max data size */ and for 32bit processes: #define MAXDSIZ32 (3U*1024*1024*1024) /* max data size */ sparc #define MAXDSIZ (512*1024*1024) /* max data size */ sparc64 #define MAXDSIZ (1*1024*1024*1024) /* max data size */ and for 32bit processes: #define MAXDSIZ32 (1*1024*1024*1024) /* max data size */ >On macppc (other powerpc platforms?) it appears to be: powerpc #define MAXDSIZ (1024*1024*1024) You could build a custom kernel that overrides this value, e.g options MAXDSIZ 34359738368 would set a limit of 32GB. But on some platforms the limits reflect whatever the hardware supports, and obviously going beyond this will not work. There might be also limitations in the virtual memory code that prevent a larger MAXDSIZ from functioning. Since netbsd-6 the data size limit doesn't actually limit the amount of memory a process can malloc(). The data size limit is used by brk()/sbrk() that extended the 'data segment' of a process. It doesn't affect mmap() which can be used to map anonymous memory outside the 'data segment', and that's what malloc() is using now. mmap() looks at the new 'address space limit' (ulimit -v) instead. Greetings,
