Re: amiboot - tlsfmem
Hi Chris,
On Tue, 6 Jan 2009, Chris Hodges wrote:
> You wrote on 05.01.09:
>
> >> avail flush
> >>
> >> Type Available In-Use Maximum Largest
> >> chip 1678408 414680 2093088 1644460
> >> fast 29402264 3627880 33030144 27781372
> >> total 31080672 4042560 35123232 27781372
> >>
> >> amiboot
>
> >> Found 4 Blocks of Memory
> >> Block 0: 0x78154000 to 0x79e94000 (29952K)
> >> Block 1: 0x780d3000 to 0x78153000 (512K)
> >> Block 2: 0x79ee8000 to 0x79f68000 (512K)
> >> Block 3: 0x78000000 to 0x79f80000 (32256K)
> >
> > Strange, blocks 0-2 overlap with block 3?
> >
> >> 36K of CHIP memory
> >
> > That's indeed not much...
>
> TLSFMem does not use a linear linked list of chunks, otherwise it wouldn't
> be able to achieve its O(1) time complexity.
>
> On startup of TLSFMem, the old AmigaOS memory headers with the remaining
> free memory* are converted to a new format, with the mh_First field set to
> NULL, as there are no longer a compatible linked chunk list and programs
> traversing the internal memory lists would probably do no good to them.
>
> * all free memory chunks that are larger than 512 KB are converted, hence
> if big memory blocks already are fragmented, there will be multiple memory
> headers for each of these chunks. These memory headers are sorted by the
> size of the chunks, so the biggest block will be accessed first.
>
> If a memory header cannot be converted completely (e.g. because there
> already was memory allocated in the old format and this memory still needs
> to be freeable), an additional old version of the memory header remains
> with remaining free chunks or chunks that are freed later. This is what you
> probably see with the 36KB of chip memory. Also, on these headers the
> mh_Lower and mh_Upper ranges may be overlapping with the TLSF memory
> headers, but only, if the TLSF headers does not reach the end of the
> original memory range.
Thanks for your explanation!
> >> The kernel will be located at 0x78154000
> >> Not enough Chip RAM in this system. Aborting...
>
> If the Linux loader would be using the exec allocation functions and not
> some private exec magic, the memory could be allocated normally.
The Linux loader uses the exec allocation functions to allocate memory while
AmigaOS is still active. However, it needs to find out about all physically
present memory, to pass this information to the Linux kernel. That's why it
walks SysBase->MemList.lh_Head.
With TLSF enabled this fails. Is there any other way to obtain this
information? Or do TLSF users have to hardcode this information in a memfile?
> > From looking at the code, a possible cause of the apparent lack of Chip RAM is
> > that there are now multiple memory headers with the MEMF_CHIP flag set. In that
> > case, bi.chip_size will be set to the size of the last header.
>
> If this is the case, you're probably looking at the legacy memory header
> which has a very low priority and is behind the new TLSF memory headers.
OK, that explains it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Reply to: