Re: cross compiling on Amiga

[mlelstv%serpens.de@localhost (Michael van Elst)]

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
>out.

A process shows here (running -current) the following limits:

datasize     32768 kbytes    = 32MB
stacksize    2048 kbytes     = 2MB
memoryuse    491520 kbytes   = 480MB
vmemoryuse   unlimited

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
consisting of:

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
actually used.

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.


Greetings,
-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."