From owner-freebsd-performance@FreeBSD.ORG Wed Nov 23 20:15:20 2005 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8A6716A41F for ; Wed, 23 Nov 2005 20:15:20 +0000 (GMT) (envelope-from m@obmail.net) Received: from stewie.obfuscated.net (stewie.obfuscated.net [66.118.188.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55A9843D46 for ; Wed, 23 Nov 2005 20:15:20 +0000 (GMT) (envelope-from m@obmail.net) Received: from [192.168.1.100] (unknown [66.118.181.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by stewie.obfuscated.net (Postfix) with ESMTP id CFEF66141; Wed, 23 Nov 2005 15:15:19 -0500 (EST) In-Reply-To: <20051123195647.27712.qmail@web30307.mail.mud.yahoo.com> References: <20051123195647.27712.qmail@web30307.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <61C1776C-7192-41D8-AE6E-65319B141259@obmail.net> Content-Transfer-Encoding: quoted-printable From: Michael Conlen Date: Wed, 23 Nov 2005 15:15:18 -0500 To: =?ISO-8859-1?Q?Arne_W=F6rner?= X-Mailer: Apple Mail (2.746.2) Cc: freebsd-performance@freebsd.org Subject: Re: mmap() X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2005 20:15:20 -0000 On Nov 23, 2005, at 2:56 PM, Arne W=F6rner wrote: > --- Michael Conlen wrote: >> On Nov 23, 2005, at 1:20 PM, Arne W=F6rner wrote: >>> Maybe the stack size matters in ur case somehow? I can see, >> that >>> it is limited to 1GB, isn't it? >>> >>> I found something funny, too: >>>> limit >>> cputime unlimited >>> filesize unlimited >>> datasize 524288 kbytes >>> stacksize 65536 kbytes >>> coredumpsize unlimited >>> memoryuse unlimited >>> vmemoryuse unlimited >>> descriptors 6861 >>> memorylocked unlimited >>> maxproc 3430 >>> sbsize unlimited >>>> c++ -o mmap mmap.c >>>> ./mmap 757254143 >>> sz2d22c7ff00000 r673435648 errno0 >>>> cat mmap.c >>> #include >>> #include >>> #include >>> #include >>> >>> int main(const int argc, char ** argv) { >>> void * r =3D >>> >> > mmap(0,atoi(argv[argc-1])*1024LL*1024,0,MAP_ANON|MAP_PRIVATE,-1,0); >>> printf("sz%llx r%d >>> errno%d\n",atoi(argv[argc-1])*1024LL*1024,r,errno); >>> return 0; >>> } >>> >>> >>> -Arne >>> >> >> At this point I have updated the kernel to include >> 2 GB for stack and data size and edited the >> loader.conf to include those options as well >> with the same result. I really believe the system is >> being limited elsewhere. >> > But why can I get so much memory (722TB) with mmap (even with the > default MAXDSIZ in my kernel)? > > Maybe we use mmap(2) the wrong way (I just used it with files: I > found it fancier to write to a file via mmap(2)'ed memory)? Well, I'm not trying to use mmap() this way per say, java 1.4.2 and =20 1.5.0 built from ports is. I have verified that I can malloc() much more memory that I can mmap=20 (). I'm looking at the code for mmap() and I can't find a resource =20 limit that would normally return ENOMEM that is set too low. -- Michael Conlen=