linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wayne Whitney <whitney@math.berkeley.edu>
To: iv@spylog.com, <linux-kernel@vger.kernel.org>
Subject: Re: Memory allocation
Date: Tue, 27 Feb 2001 09:51:25 -0800	[thread overview]
Message-ID: <200102271751.f1RHpP401022@adsl-209-76-109-63.dsl.snfc21.pacbell.net> (raw)
In-Reply-To: <004901c0a0de$2647d6c0$0e04a8c0@iv>
In-Reply-To: <004901c0a0de$2647d6c0$0e04a8c0@iv>

In mailing-lists.linux-kernel, you wrote:

>I encountered with problem: one process can not allocate more then 2Gb of
>memory. 

This is a problem that I have run into myself.  I am no kernel expert,
but I think I understand how this issue.  Here is how the standard
kernel maps the 4Gb 32-bit address space from the process's point of
view:

128MB	 program executable mapped (twice)
128MB +	 program heap
1GB	 mmap() starts here
3GB	 kernel

You can see this for yourself by looking at /proc/pid/maps, where pid
is the PID of the process in question.  

Now glibc()'s malloc uses mmap() for 'large' allocations, so you get
2GB maximum memory.  The way around this is to change the various
numbers in the left-hand column.

For example, you can try the patch per-process-3.5G-IA32-no-PAE-1, at
/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test11-pre5/ on
ftp.kernel.org.  This will make the kernel space start at 3.5G (so
that CONFIG_4G is required to use more than 384MB of physical RAM) and
the mmap() space start at 224MB, giving 3G288MB of address space for
mmap().  Note that only 96MB is then available for {two copies of your
executable plus your program heap}.

This is more or less the most you can do, but your needs may be best
suited by something in between. The above patch is quite short, so it
is easy to figure out how to do that.  The only hidden restriction is
that the size of the kernel space must be a power of 2: 2GB, 1GB,
512MB, etc.  As explained to me, this is so that the kernel can easily
test a pointer to see whether it is to kernel space or user space.

Cheers,
Wayne





  reply	other threads:[~2001-02-27 17:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-27 16:55 Memory allocation Ivan Stepnikov
2001-02-27 17:51 ` Wayne Whitney [this message]
2001-02-27 17:55 ` Peter Samuelson
2003-09-14 18:44 1:1 M:N threading Breno
2003-09-14 19:11 ` Robert Love
2003-09-16 15:04   ` Memory allocation Breno
2007-04-17  2:17 Memory Allocation Brian D. McGrew
2007-04-17  7:06 ` Eric Dumazet
2007-04-18  4:47 ` David Schwartz
     [not found] <fa.BkbRyK9fXhgijRwEDN4ejyJhMRQ@ifi.uio.no>
2007-04-17  5:08 ` Robert Hancock

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=200102271751.f1RHpP401022@adsl-209-76-109-63.dsl.snfc21.pacbell.net \
    --to=whitney@math.berkeley.edu \
    --cc=iv@spylog.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).