lkml.org 
[lkml]   [2002]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: mmap'ing a large file
Gianni Tedesco wrote:
> On Wed, 2002-08-14 at 16:42, Mike Black wrote:
> > Is there a logical reason why a process can't mmap more than a 2G file?
> >
> > I seem to get stuck at 2142208000 with
> > mmap: Cannot allocate memory
>
> Perhaps this should be an FAQ item.
>
> Intel is a 32bit architecture, that is to say the address space is 2^32
> bytes (4GB), of this address space the kernel takes the top 2GB and
> userspace the bottom 2GB.

No, firstly those numbers are incorrect and secondly, that's not the
reason why Mike's program stops at 2142208000.

The standard kernel's address space provides exactly 3GB for userspace.
The range of user addresses is 0x00000000 to 0xbfffffff. So the
absolute maximum that can be mmaped at a time is a little under 3GB.

The reason why Mike's program won't mmap() more than about 2GB of the
file is for two reasons:

1. mmap() will search for a free address starting at 0x40000000, up to
0xbffff000. It won't search lower addresses, unless you give it a
hint, and the hinted address is actually unmapped. I think this is
to reserve about 1GB for brk().

2. The executable and shared libraries take some room, too.

Btw Mike, the original program uses `p' uninitialised. If you weren't
so lucky (say if the stack is initialised differently) you could get
much less than 2GB.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.068 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site