[okl4-developer] OKL4 v2.1: About memory layout

[Malcolm Purvis]

>>>>> "Frank" == Frank Kaiser <frank.kaiser at opensynergy.com> writes:

Frank> The conclusion is that the memory allocation algorithm carried
Frank> out be the GNU loader under control of the ELF Adorn and ELF
Frank> Weaver tools is somewhat unpredictable, and I do not see why the
Frank> manipulation of the heap size has such a significant effect.

Hi Frank,

Thanks for your questions about the kernel heap.

The location of the kernel heap is driven by the need to minimise the
number of TLB entries used by the kernel and to have very simple
virt->phys mapping code for kernel structures.  Consequently, the heap
must be:

1) Within 64MB of the kernel in physical memory

2) Aligned to the biggest page size that covers the kernel heap.

As you've seen, this results in a 4M kernel being put on a 1M boundary.

To ensure that these constraints are met memory for the kernel heap is
allocated after memory for the kernel and before any other object.  This
will normally put the heap at the first suitably aligned address (1M by
default) above the kernel.  If the rest of the image is larger than a 1M
this will unfortunately leave the a hole in the image, unless you
explicitly set physical address of the heap.

The allocation policy can certainly be improved, and this is something
that we should look into in a future release.

Incidentally, if you run elfweaver manually with the --map option, it
will print an memory map of the objects that it has allocated.  

./tools/pyelf/elfweaver merge --map -o build/images/image.elf build/images/weaver.xml

Malcolm

-- 
                    Malcolm Purvis <malcolmp at ok-labs.com>