From owner-freebsd-hackers Mon Dec 7 21:51:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA15136 for freebsd-hackers-outgoing; Mon, 7 Dec 1998 21:51:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA15131 for ; Mon, 7 Dec 1998 21:51:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id VAA35618; Mon, 7 Dec 1998 21:51:03 -0800 (PST) (envelope-from dillon) Date: Mon, 7 Dec 1998 21:51:03 -0800 (PST) From: Matthew Dillon Message-Id: <199812080551.VAA35618@apollo.backplane.com> To: Charles Henrich Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Large memory size per process? References: <19981205100451.10207@orbit.flnet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :When compiling a kernel with 2GB for the max DSIZ we get integer overflows all :over the place. At 1.5GB we only get one in the elf loader, and it seems to :work okay set that way. 2GB I get all sorts of overflows in the vm subsystem :and havent tried to run that way. Due to this Im assuming that its impossible :to get large processes in FreeBSD without some major work, is this true? : :-Crh : : Charles Henrich Manex Visual Effects henrich@flnet.com : : http://orbit.flnet.com/~henrich : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-hackers" in the body of the message Hmm. Well, it looks like it should be possible. imgact_elf.c would be a problem. kern/kern_resource.c would be ok if MAXDSIZ were cast to unsigned or turned into a quad_t or rlim_t. The other instances would require overflow checks but ought to work reasonably well. However, increasing MAXDSIZ decreases the VM space available for mmap() and SysV shared memory and could create other problems. Are you actually running a program that uses that much data space or is your program using mmap()? You may be able to work around the problem temporarily by using a smaller MAXDSIZ and instead using mmap() to allocate memory. -Matt apollo:/usr/src/sys# fgrep MAXDSIZ */*.c kern/imgact_elf.c: addr = 2L*MAXDSIZ; /* May depend on OS type XXX */ kern/kern_resource.c: if (limp->rlim_cur > MAXDSIZ) kern/kern_resource.c: limp->rlim_cur = MAXDSIZ; kern/kern_resource.c: if (limp->rlim_max > MAXDSIZ) kern/kern_resource.c: limp->rlim_max = MAXDSIZ; kern/sysv_shm.c: attach_va = round_page((vm_offset_t)p->p_vmspace->vm_taddr + MAXTSIZ + MAXDSIZ); vm/vm_glue.c: p->p_rlimit[RLIMIT_DATA].rlim_max = MAXDSIZ; vm/vm_mmap.c: else if (addr < round_page((vm_offset_t)p->p_vmspace->vm_daddr + MAXDSIZ)) vm/vm_mmap.c: addr = round_page((vm_offset_t)p->p_vmspace->vm_daddr + MAXDSIZ); Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message