Date: Sat, 11 Nov 2000 19:48:05 -0500 From: Michael Joyner <wolfieee@wolf.dyns.cx> To: Mitch Collinsworth <mitch@ccmr.cornell.edu> Cc: freebsd-questions@freebsd.org Subject: Re: Linux malloc better on FreeBSD than FreeBSD malloc? Message-ID: <3A0DE8C5.63F542E9@wolf.dyns.cx> References: <Pine.LNX.4.10.10011111741520.16421-100000@dragon.ccmr.cornell.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <stdio.h>
> > > #include <stdlib.h>
> > > #include <unistd.h>
> > >
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A0DE8C5.63F542E9>