Date: Sun, 11 Mar 2001 23:28:41 -0800 From: Paul Saab <ps@mu.org> To: Alfred Perlstein <bright@wintelcom.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Greater than 2GB per process Message-ID: <20010311232841.A20355@elvis.mu.org> In-Reply-To: <20010311205023.P18351@fw.wintelcom.net>; from bright@wintelcom.net on Sun, Mar 11, 2001 at 08:50:24PM -0800 References: <Pine.LNX.4.31L2.0103120005460.9179-100000@pachabel.ednet.co.uk> <20010311204130.N18351@fw.wintelcom.net> <003701c0aaaf$a4566ce0$dc02010a@fireduck.com> <20010311205023.P18351@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein (bright@wintelcom.net) wrote:
> * Joseph Gleason <clash@tasam.com> [010311 20:48] wrote:
> >
> > ----- Original Message -----
> > From: "Alfred Perlstein" <bright@wintelcom.net>
> > To: "Ian Campbell" <ianc@ednet.co.uk>
> > Cc: <freebsd-hackers@FreeBSD.ORG>
> > Sent: Sunday, March 11, 2001 23:41
> > Subject: Re: Greater than 2GB per process
> >
> >
> > > * Ian Campbell <ianc@ednet.co.uk> [010311 16:14] wrote:
> > > >
> > > > Hello,
> > > > Could anybody advise me on the possiblity of having greater than
> > > > 2GB per process on FreeBSD. I have tried increasing the limit beyond
> > this
> > > > and the kernel compiles successfully - however libc causes every process
> > > > to segfault. I am assuming that just recompiling the C library wouldn't
> > do
> > > > the trick but perhaps someone could confirm this.
> > >
> > > It's not possible on the Intel archetecture with the current system,
> > > changing the current intel system to use > 2GB processes would cost too
> > > much in terms of performance (64 bit values on a 32 bit system).
> > >
> > > At least that's what i've been told.
> > >
> >
> > I know very little about how kernel or low level processor stuff works, but
> > shouldn't we be able to do a 4GB process on a 32-bit system?
> > The limitation of 2GB per process should only be an issue if there is some
> > need to use signed numbers, right?
>
> Yes, we use signed numbers. Check the list archives, there's some
> pretty detailed discussions that explain why it's this way.
Actually.. the kernel and userspace processes use the same address space
and since the kernel take 1GB of the address apce, you then have 512MB
allocated for the malloc pool and the rest is allocated to malloc, so
techinically you can mmap 2.5GB of memory, but according to the manual
page of mmap..
BUGS
len is limited to 2GB. Mmapping slightly more than 2GB doesn't work, but
it is possible to map a window of size (filesize % 2GB) for file sizes of
slightly less than 2G, 4GB, 6GB and 8GB.
The limit is imposed for a variety of reasons. Most of them have to do
with FreeBSD not wanting to use 64 bit offsets in the VM system due to
the extreme performance penalty. So FreeBSD uses 32bit page indexes and
this gives FreeBSD a maximum of 8TB filesizes. It's actually bugs in the
filesystem code that causes the limit to be further restricted to 1TB
(loss of precision when doing blockno calculations).
Another reason for the 2GB limit is that filesystem metadata can reside
at negative offsets.
asd We currently can only deal with page aligned file offsets.
b
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010311232841.A20355>