Re: Can a process use up more than 910MB?

[Tim Walberg]

--NDin8bjvE/0mNLFQ
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

On 01/06/2000 18:39 +0100, Peter Tufvesson wrote:
>>=09
>>=09
>>	Ok, I have now made some more investigation.
>>=09
>>	This is my understanding of how (part of) the process memory space is us=
ed
>>=09
>>	0x0 - 0x40000000 : Used by brk(). It starts low and grows up. Close to 1=
GB
>>	0x4000000 - 0xc0000000 : Used by mmap(). It starts low and grows up. 2GB
>>	0xfffffff - ? : Used by the stack. It starts high and grows down. 1GB.
>>=09
>>	Is this correct? If so, WHY???
>>=09
>>	By doing this, you have effectively limited the amount of mmap()ped memo=
ry
>>	to 2GB and the amount of brk()ed memory to 1GB. So even if the process
>>	memory is in total 3GB, it is very unlikely that a process uses more than
>>	1GB or 2GB (depending if it uses mmap() or brk() )
>>=09
>>	Solaris, on the other hand, lets the mmap() region start high at 0xf4000=
00
>>	and grow down. This way, the process is entitled to 3GB of EITHER brk() =
or
>>	mmap() memory!
>>=09
>>	Am I totally wrong, or can the Linux code be dramatically and
>>	easily improved?
>>=09

I'm going from (potentially flaky) memory here, so don't
torch me too bad if I get something wrong. I don't remember
the address boundaries exactly, but I think Solaris
uses the following memory layout:

	0-end_text		program text
	end_text-???		heap (or brk(), whatever you want
				to call it)
	???-stack_start		mmap area, including dynamic
				libs, growing down
	stack_start-2GB		stack - usually a fixed size considerably
				smaller than 1GB
	2GB-4GB			kernel - inaccessible to user mode

stack size is configurable using certain compiler/linker options,
but there is essentially a 2GB vm limit per process. This has
probably changed since the 64 bit chips have come out, but I haven't
had the same level of experience with them that I had with the
32 bit architecture - I would assume that they used a fairly similar
model. That layout seems to provide a little more flexibility in
the balance between mmap/heap areas, although a badly fragmented
heap could still potentially interfere with mmap-ing.

I agree the (seemingly arbitrary?) 1GB/2GB/1GB split could
probably be improved on quite a bit, but I have no idea how
much work that would entail... I suspect quite a lot...
Then again, maybe there are completely valid reasons for
the current state of affairs that I'm not aware of (actually,
I'd almost bet on that...).

					tw

--=20
+--------------------------+------------------------------+
| Tim Walberg              | [e-mail]       |
| 828 Marshall Ct.         | www.concentric.net/~twalberg |
| Palatine, IL 60074       |                              |
+--------------------------+------------------------------+

--NDin8bjvE/0mNLFQ
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: ceVY19kchDU7n7/HCEYnDxLRS2QbQIZV

iQA/AwUBOHUKhMPlnI9tqyVmEQJc3gCgh4vKMDAGwpD24gpEhWGKwq9aOEoAni43
SaIsT6VsyJuByXcxrfjBelDs
=pVRy
-----END PGP SIGNATURE-----

--NDin8bjvE/0mNLFQ--