From owner-freebsd-questions Sat Nov 11 16:48:26 2000 Delivered-To: freebsd-questions@freebsd.org Received: from wolf.dyns.cx (dws40-46.jacksonville.net [24.129.40.46]) by hub.freebsd.org (Postfix) with ESMTP id 9C22D37B479 for ; Sat, 11 Nov 2000 16:48:20 -0800 (PST) Received: from wolf.dyns.cx (ip100.internal [192.168.255.100]) by wolf.dyns.cx (8.9.3/8.9.3) with ESMTP id TAA07548; Sat, 11 Nov 2000 19:48:17 -0500 (EST) (envelope-from wolfieee@wolf.dyns.cx) Message-ID: <3A0DE8C5.63F542E9@wolf.dyns.cx> Date: Sat, 11 Nov 2000 19:48:05 -0500 From: Michael Joyner X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mitch Collinsworth Cc: freebsd-questions@freebsd.org Subject: Re: Linux malloc better on FreeBSD than FreeBSD malloc? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG not about the linux binary thing. but about the apparant top max total. and like I said, just a shot in the dark. :) Mitch Collinsworth wrote: > > I'll check those out, but just to be clear, are you suggesting these > could explain why the Linux binary running on FreeBSD was able to do > what the FreeBSD binary could not? > > -Mitch > > On Sat, 11 Nov 2000, Michael Joyner wrote: > > > a shot in the dark... > > think this comment from LINT might help? > > # > > # Certain applications can grow to be larger than the 128M limit > > # that FreeBSD initially imposes. Below are some options to > > # allow that limit to grow to 256MB, and can be increased further > > # with changing the parameters. MAXDSIZ is the maximum that the > > # limit can be set to, and the DFLDSIZ is the default value for > > # the limit. You might want to set the default lower than the > > # max, and explicitly set the maximum with a shell command for processes > > # that regularly exceed the limit like INND. > > # > > options MAXDSIZ="(256*1024*1024)" > > options DFLDSIZ="(256*1024*1024)" > > > > > > Mitch Collinsworth wrote: > > > > > > Well I hope that subject was provocative enough to generate some > > > interest! :-) Here's a strange situation that's bugging me. I > > > recently changed jobs, into a dept that's heavily Linux-based. I > > > of course have different preferences, but need to demonstrate > > > technical superiority if any changes are going to happen. An > > > opportunity just arose to make some comparisons between Linux and > > > FreeBSD in maximum process size. We have some new systems with > > > 4 GB RAM each that will be made available for running large batch > > > jobs. > > > > > > We have a very simple test program that malloc's successively larger > > > and larger blocks of memory until it fails, freeing the current blocks > > > after each successful trial. The strange thing is that the test > > > program runs much farther on FreeBSD using the Linux binary in > > > compatibility mode than it does using the binary compiled on FreeBSD! > > > Included below are the output from each binary and the source. Can > > > anyone explain these results? > > > > > > A second question, which is the primary issue we were trying to > > > discover is if it is possible for a single process to malloc more than > > > 2 GB of memory. FreeBSD supposedly supports up to 4 GB (on Intel > > > hardware), but does anyone know if there is still a 2 GB per process > > > limit? And if a single process can be larger than 2 GB, is there a > > > 2 GB limit on any single malloc with that process? > > > > > > For comparison purposes, the Linux answers to these questions are that > > > with a special "bigmem" patch installed, a process can be larger than > > > 2 GB, but any single malloc is still limited to 2 GB. > > > > > > The system the tests are being run on is a 900 MHz Xeon running > > > FreeBSD 4.1-R with 1 GB RAM and 18 GB swap: > > > > > > ruby> swapinfo -k > > > Device 1K-blocks Used Avail Capacity Type > > > /dev/da0s3b 511872 0 511872 0% Interleaved > > > /dev/rda1c 17783108 0 17783108 0% Interleaved > > > Total 18294980 0 18294980 0% > > > > > > ------FreeBSD results--------- > > > # with FreeBSD compiled binary > > > ruby> ./grab-fbsd > > > Allocated f 268435455 > > > Punt g at 268435455 > > > > > > # with Linux compiled binary run in compatibility mode > > > ruby> ./grab-linux > > > Allocated f 268435455 > > > Allocated g 268435455 > > > Allocated f 536870911 > > > Allocated g 536870911 > > > Allocated f 805306367 > > > Allocated g 805306367 > > > Allocated f 1073741823 > > > Allocated g 1073741823 > > > Allocated f 1342177279 > > > Punt g at 1342177279 > > > > > > ------source----------------- > > > #include > > > #include > > > #include > > > > > > int > > > main(int argc, char *argv[]){ > > > > > > unsigned long i, s2; > > > char *foo, *goo; > > > > > > for (i=1; i<100; i++){ > > > foo = (char *) malloc(s2=(unsigned long)i*(1024*1024*256)-1); > > > if ( foo == NULL) { > > > printf("Punt f at %lu\n", s2); > > > exit(1); > > > } else { > > > printf("Allocated f %lu\n",s2); > > > } > > > goo = (char *) malloc(s2=(unsigned long)i*(1024*1024*256)-1); > > > if ( goo == NULL) { > > > printf("Punt g at %lu\n", s2); > > > exit(1); > > > } else { > > > printf("Allocated g %lu\n",s2); > > > } > > > sleep(4); > > > free(foo); > > > free(goo); > > > } > > > } > > > ----------------------------- > > > > > > Thanks for any help. Please cc: me on replies. I'm no longer getting > > > -questions directly. > > > > > > -Mitch > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-questions" in the body of the message > > > > -- > > > > === > > Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. > > === > > --- > > Michael Joyner > > Systems Administrator > > mjoyner@rv1.dynip.com > > -- === Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. === --- Michael Joyner Systems Administrator mjoyner@rv1.dynip.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message