memory limits....

[markw at mohawksoft.com (markw at mohawksoft.com)]

> Message: 8
> Date: Thu, 19 May 2005 11:56:17 -0400
> From: Jerry Feldman <gaf at blu.org>
> Subject: Re: memory limits....
> To: discuss at blu.org
> Message-ID: <200505191156.17759.gaf at blu.org>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> On Thursday 19 May 2005 11:32 am, markw at mohawksoft.com wrote:
>
>> 32bit code on a pentium or higher is limited to 4G per process.
>>
>> Way back when, the OS took up the top two gigs, and left the bottom 2G
>> for user space. More recently, with larger memory requiements, the OS
>> started to give up some of its two gig space back to applications.
>>
>> A lot of things affect how much space the OS takes up in shared space.
>> It
>> is hard to say for sure unless we know more.
>>
>> If you need much more than 2G in user space, consider 64bit Linux.
> When talking about memory that a program can use, one needs to talk about
> virtual space. Virtual space has no relationship to the actual memory that
> is installed.

This is true, but a addressability of a process operating in 32 bit mode
is limited to 32 bits, or 4G. I never mentioned, anywhere, "actual
memory," and was refering to the virtual memory manager of the x86 (>=
386)


> For instance, I mentioned that your program is divided up into chunks:
> 1. Text - this is read only. Your program text segment is mapped to
> virtual
> memory and is not copied to swap. It's pages are swapped in when needed.

It is hard to say exactly. I haven't read up the specifics of how the
Linux kernel is currently dealing with the various issues with VM. (It has
changed a couple times as I recall)

Classically, text segments are not "swapped," but if they are modified at
load time, they may be paged out.

I also don't like to use the term "swapped." I think "paged" is sort of
better, because the virtual memory mapping of the 386 works in 4K or
(optional 4M pentium) pages. Swapping I associate with the 80286 segment
based swapping.

> 2. Initialized data. This is generally loaded into memory and copied to
> swap. (The specific strategy depends on the OS's VM and may change between
> releases).
> 3. Unitialized data. The pages here are created when accessed, and swapped
> to swap space when needed. (This is the bss segment).
> 4. Stack the stack can be allocated as part of the data areas.
> 5. Heap. The classic heap grows (upwards in most systems). This uses the
> brk(2) or sbrk(2) calls. It can stop when it reaches the top of the user's
> virtual map or if something has been allocated above it.

exactly.

> 6. mmaped memory. This is memory you can allocate yourself. You can also
> make this sharable. If malloc(3) fails, you could use mmap(2) and try to
> manage memory yourself.

This sort of makes sense. Typically the OS has a process memory boundary,
under which is user space, over which is OS space. "malloc" et al map
memory into the user process side. The mmap function, if mapping shared
memory, should map memory into the OS or shared space.

Please note: while the shared space address range is typically present in
every proces, it may not be "mapped" into that space in the processes page
descriptor table.