[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: cross compiling on Amiga
abs%NetBSD.org@localhost (David Brownlee) writes:
>So theoretically two machines with a 2G/2G userland/kernel virtual
>memory split, one with 64M and the other 2G, both with over 2GB of
>swap space should be able to allocate 2G of space to a (single)
>process. One will just be much slower to run as it pages memory in and
A process shows here (running -current) the following limits:
datasize 32768 kbytes = 32MB
stacksize 2048 kbytes = 2MB
memoryuse 491520 kbytes = 480MB
The pmap command shows the virtual memory map of a process.
- The program starts at 8k (the pagesize is 8k, and the first
page is left unused to trap NULL pointers).
- At 128.25MB shared libraries including the runtime linker are mapped,
- The stack area starts at 448MB and the virtual address
space of the process ends at 480MB.
Between these 3 parts there is unallocated address space that is used
for dynamic memory allocations. Older malloc code would only use
the first hole, so a program could allocate about 128MB minus the size
of the program. The second hole could only be used by using mmap()
to allocate anonymous memory (like malloc) or to memory map files.
But the current malloc code can use either.
A program that mallocs 1MB memory chunks in a loop until malloc returns NULL
will get 349MB.
Here is the address map of the running program after the allocation of 349MB.
00002000 8K read/exec /home/guest/large
00004000 2032K read/write [ anon ]
00200000 1024K read/write [ anon ]
00300000 1024K read/write [ anon ]
01E00000 1024K read/write [ anon ]
01F00000 1024K read/write [ anon ]
08004000 56K read/exec /libexec/ld.elf_so
08012000 8K read/write [ anon ]
08014000 8K read/exec [ uvm_aobj ]
08016000 32K read/write [ anon ]
0801E000 976K read/exec /lib/libc.so.12.183
08112000 56K read/write /lib/libc.so.12.183
08120000 96K read/write [ anon ]
08200000 1024K read/write [ anon ]
08300000 1024K read/write [ anon ]
1BE00000 1024K read/write [ anon ]
1BF00000 1024K read/write [ anon ]
1C000000 30720K [ stack ]
1DE00000 1920K read/write [ stack ]
1DFE0000 128K read/write [ stack ]
Apparently 96GB before the start of the shared libraries are not used.
That's because malloc only uses the first hole up to the datasize limit.
When the datasize limit is set to unlimited, the program allocates
the full 445MB instead.
To map 4GB of address space for a process, you use a 3-level MMU table
1 root table (0.5 kB)
128 pointer tables (64 kB)
16384 page tables (2048 kB)
The kernel allocates 2MB (M68K_MAX_PTSIZE) for the page tables, but
it only gets 8 kB (M68K_STSIZE) for 1 root and 15 pointer tables.
This limits the page map to represent only 480MB of virtual memory.
If you think the 2MB page tables are wasted... only address space for
this is allocated, memory is only assigned when those page tables are
The kernel uses a 32bit mask to manage the pointer tables, so it is
probably simple to modify the kernel to allow for 992MB virtual memory
per process (31 pointer tables). Anything larger will require changes
to the code.
On the other hand, the root and pointer tables are wired. You should
have enough real memory (and kernel address space) for this.
Michael van Elst
"A potential Snark may lurk in every tree."
Main Index |
Thread Index |