SUMMARY: large mmap(2)

From: Claude Scarpelli (claude@genethon.genethon.fr)
Date: Tue Oct 15 1991 - 18:34:38 CDT


in a *very* recent posting (thanks Sun-Managers!), I was having
trouble mmap(2)'ing a very large region (1-2Gbytes)

I thought it was related to the datasize limit. So I tried to
increase the size of the data segment, without success

Dave Probert (probert@cs.ucsb.edu) give me very usefull information
(See his posting at the end of this letter) :

"There is a hole in the MMU between virtual addresse 0x20000000 - 0xdfffffff"

This is right only for 4/20..4/75 ; With my 4/470, the datasize
limit is 2 Gb.

1) the datasize limit in a Sparc 1 or Sparc 2 can't be increased over
0x20000000 (524288 KB). It's a hard limit. Modifying /sys/sun4c/vmparam.h
doesn't change anything.

2) You can't mmap more than this value. Moreover, the sum of the mmaps
in your program can't exceed 524288 KB

3) on a 4/470 (where the datasize limit is 2Gb and where there is no
hole in the MMU), you can mmap more than 2Gb ; The limit seems
to be around 3.5 Gb ; Be careful, you can't map more than 2 Gb
in one mmap syscall. So, to map 3.5 Gb, you have to do at least
2 syscalls (I think it's a bug in mmap : If len > 2 Gb, then
it becomes < 0... and ernno is set to EINVAL ; There are same
things in write(2)). I think it's better not to go beyond the 2Gb limit...

The following test completes (on the 4/470):
        open
        truncate 2Gb
        mmap 2Gb
        write 1 byte each 20 Mb
        munmap - close

        The created file was 2Gb, with 2000 blocks allocated
        (as reported by ls -ls) : Succeeded.

Some people speculate on the missuse of csh'limit ; Sorry, it was
not that !

Special thanks to Dave Probert <probert@cs.ucsb.edu>
and to
mattson@cs.UCSD.EDU
Hans van Staveren <sater@cs.vu.nl>

------------------------------------------------------------------------------
Claude Scarpelli Internet : claude@genethon.fr
Human Polymorphism Study Center or : claude@cephb.fr

Included message :
----------------

----- Begin Included Message -----

>From probert%cs@hub.ucsb.edu Mon Oct 14 20:25:58 1991
Received: from hub.ucsb.edu by genethon.genethon.fr, Mon, 14 Oct 91 20:25:37 +0100
Received: from orcas (orcas.ucsb.edu) by hub.ucsb.edu; id AA02566
        sendmail 4.1/UCSB-2.0-sun
        Mon, 14 Oct 91 12:26:52 PDT for claude@genethon.genethon.fr
Message-Id: <9110141926.AA02566@hub.ucsb.edu>
Received: from by orcas (4.1) id AA17502; Mon, 14 Oct 91 12:25:15 PDT
Date: Mon, 14 Oct 91 12:25:15 PDT
From: Probert <probert%cs@hub.ucsb.edu>
Posted-Date: Mon, 14 Oct 91 12:25:15 PDT
To: claude@genethon
In-Reply-To: Claude Scarpelli's message of Mon, 14 Oct 91 16:22:15 +0100 <9110141522.AA24258@genethon.genethon.fr>
Subject: large mmap(2)
Reply-To: probert%cs@hub.ucsb.edu
Status: R

Perhaps this information will help. In the Sparc MMU architecture (the
current one, not the new reference one which first appears in Galaxy),
there is a hole in the mmu between virtual addresses

        0x20000000 - 0xdfffffff

        [(echo hole_start/X; echo hole_end/X) | adb /vmunix /dev/kmem]

0x20000000 = 524288 KB.

So this is a hard limit in the hardware for the size of the data segment.

--
Dave Probert
probert@cs.ucsb.edu

----- End Included Message -----



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:18 CDT