From: ebiederm+eric@ccr.net (Eric W. Biederman)
To: Rik van Riel <riel@nl.linux.org>
Cc: Lee Chin <leechin@mail.com>,
Linux Kernel <linux-kernel@vger.rutgers.edu>,
Linux MM <linux-mm@kvack.org>
Subject: Re: maximum memory limit
Date: 08 Feb 2000 10:25:46 -0600 [thread overview]
Message-ID: <m166vzr791.fsf@flinx.hidden> (raw)
In-Reply-To: Rik van Riel's message of "Tue, 8 Feb 2000 15:08:49 +0100 (CET)"
Rik van Riel <riel@nl.linux.org> writes:
> On Tue, 8 Feb 2000, Lee Chin wrote:
>
> > Sorry if this is the wrong list, but what is the maximum virtual
> > memory an application can malloc in the latest kernel?
> >
> > Just doing a (for example) "malloc(1024)" in a loop will max out
> > close to 1GB even though I have 4 GB ram on my system.
>
> The kernel supports up to 3GB of address space per process.
> The first 900MB can be allocated by brk() and the rest can
> be allocated by mmap().
>
> Problem is that libc malloc() appears to use brk() only, so
> it is limited to 900MB. You can fix that by doing the brk()
> and malloc() yourself, but I think that in the long run the
> glibc people may want to change their malloc implementation
> so that it automatically supports the full 3GB...
Clarification: The problem is the brk interface, which ignores
fragmentation. The brk interface assumes all memory is
continuous. When brk runs into any mapping it fails. And since ld.so
is mapped at 1GB the brk cannot allocate any more memory. This
is agravated by the fact that ELF programs appear to be intially
mapped at 128M+288K. 0x08048000. (Someone allocated 900MB??? wow!)
It would certainly be a good option if libc could allocate
new chunks of memory with mmap, or a combination of mmap and mremap.
mremap is functionally a good as brk but will let you work with
arbitrary areas of memory.
A good option is to compile programs that need huge amounts
of memory through brk statically. If they do not use mmap, or shmat
they should be fine until they hit the stack, which is growing
in the other direction from 3GB. Because the program is static it's
code size is reduced the linker will only pull in needed objects,
and performance is also enhanced as you don't need to deal with PIC,
and register starvation. So it looks good for compute intensive code.
Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2000-02-08 16:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <381740616.949993193648.JavaMail.root@web36.pub01>
2000-02-08 14:08 ` Rik van Riel
2000-02-08 14:48 ` Matthew Kirkwood
2000-02-08 15:04 ` Mark Hahn
2000-02-08 15:25 ` Jakub Jelinek
2000-02-08 16:13 ` Rogier Wolff
2000-02-08 16:25 ` Eric W. Biederman [this message]
2000-07-02 5:35 ` Raymond Nijssen
2000-07-03 10:35 ` Stephen C. Tweedie
2000-07-03 13:32 ` Jamie Lokier
2000-07-03 14:18 ` Stephen C. Tweedie
2000-07-03 15:01 ` Jamie Lokier
2000-07-03 19:32 ` Raymond Nijssen
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=m166vzr791.fsf@flinx.hidden \
--to=ebiederm+eric@ccr.net \
--cc=leechin@mail.com \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=riel@nl.linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox