increase the hard limit on i386 max data size to 2GB-1. This will allow memory hungry processes to potentially use more RAM if you increase data limits appropriately. Index: vmparam.h =================================================================== RCS file: /home/tedu/cvs/src/sys/arch/i386/include/vmparam.h,v retrieving revision 1.45 diff -u -r1.45 vmparam.h --- vmparam.h 15 Dec 2010 05:30:19 -0000 1.45 +++ vmparam.h 24 Dec 2010 21:52:07 -0000 @@ -63,7 +63,7 @@ #define DFLDSIZ (64*1024*1024) /* initial data size limit */ #endif #ifndef MAXDSIZ -#define MAXDSIZ (1024*1024*1024) /* max data size */ +#define MAXDSIZ (2UL*1024*1024*1024-1) /* max data size. -1 to avoid overflow */ #endif #ifndef BRKSIZ #define BRKSIZ (1024*1024*1024) /* heap gap size */
On Fri, Dec 24, 2010 at 5:02 PM, Mark Kettenis <mark.kettenis@xs4all.nl> Anyone who stores the limit in a signed int (or long). Do I know of any such software? No. Am I willing to risk the possibility of such existing to squeeze out a few more bytes? No. I will happily set it to straight 2GB, or even higher if we don't care about possible trouble, so long as everybody promises not to complain if an issue is found. :)
To phrase it another way, I was actually hoping that by avoiding the "what about overflow?" worries, we could move forward faster. If that's not a worry, great, I just didn't want to get tied down.
You mean, in the kernel? There the limits are stored in rlim_t, which
is a 64-bit type on all our architectures. There is one comparison in
uvm_mmap.c that had me worried for a bit:
if (size >
(p->p_rlimit[RLIMIT_DATA].rlim_cur - ptoa(p->p_vmspace->vm_dused))) {
but this is safe since ptoa() casts to paddr_t, which is unsigned long.
There is also 'struct orlimit' in <sys/resource.h>, which is used for
BSD4.3 compat code in compat/common/kern_resource_43.c. But
RLIMIT_DATA isn't the only resource limit that can be set to 2GB or
beyond. So I'm happy to ignore that issue.
For userland, I have very little sympathy. If stuff doesn't run with
the limits cranked up all the way to 2GB, fix it, or crank the limit
I don't think this is a worry. Wouldn't mind if somebody else takes a
look at this as well.
