From: Paul Sargent <Paul.Sargent@3dlabs.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2GB process crashing on 2.4.14
Date: Fri, 7 Dec 2001 14:01:29 +0000 [thread overview]
Message-ID: <20011207140128.F31161@3dlabs.com> (raw)
In-Reply-To: <20011207132317.E31161@3dlabs.com> <E16CLM9-0005rf-00@the-village.bc.nu>
In-Reply-To: <E16CLM9-0005rf-00@the-village.bc.nu>
On Fri, Dec 07, 2001 at 01:48:00PM +0000, Alan Cox wrote:
> > > Most probably the process is running out of address space to allocate from.
> > > There is 3Gb of available space.
> >
> > That would be from 0x00000000 to 0xC0000000, Right?
>
> Correct (0xBFFFFFFF)
>
> > > binary, some your libraries. Getting above 3Gb/process on x86 is very hairy
> > > with a bad performance hit
> >
> > So if I was hitting this limit then I should see no / very few gaps, in the
> > /proc/<pid>/maps. Is that true?
>
> Providing the memory allocator it is using is sufficiently smart
Where "it" is the app?
OK, well looking at the maps output, there seems to be three distinct
sections:
1) from 0x00000000 to 0x01c6a000 (30MB-ish) are mappings of the executable.
2) from 0xbca9a000 to 0xbfffffff (56MB-ish) are the libs, plus a few other
areas, which I've assumed are stack, and scratch areas for the libs.
3) a single mapping, (was 1.1GB-ish in the map output I attached) which
starts at the end of section 1, and is continually growing, and which I
can see has no reason to stop until it gets to the start of section 2
(some 3GB - 86MB later).
Now admittedly, it's possible that some of the other mappings may grow by a
factor of 20 to suddenly eat up 1GB of address space, but I doubt it. So I'm
not buying the address space idea at the moment. That said, I'm not going to
discount it and will keep a log of what happens on the mappings while this
process is running, just in case something really wacky like that happens.
Paul
--
Paul Sargent
mailto: Paul.Sargent@3Dlabs.com
next prev parent reply other threads:[~2001-12-07 14:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-07 12:58 2GB process crashing on 2.4.14 Paul Sargent
2001-12-07 13:16 ` Alan Cox
2001-12-07 13:23 ` Paul Sargent
2001-12-07 13:48 ` Alan Cox
2001-12-07 14:01 ` Paul Sargent [this message]
[not found] <20011207125821.D31161@3dlabs.com.suse.lists.linux.kernel>
[not found] ` <E16CKrx-0005nL-00@the-village.bc.nu.suse.lists.linux.kernel>
[not found] ` <20011207132317.E31161@3dlabs.com.suse.lists.linux.kernel>
2001-12-07 14:02 ` Andi Kleen
2001-12-07 14:15 ` Paul Sargent
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011207140128.F31161@3dlabs.com \
--to=paul.sargent@3dlabs.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.