Re: amiboot - tlsfmem
Huhu Geert,
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.
>> 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.
> 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.
--
Regards, Chris Hodges )-> http://www.platon42.de <-(
GCS/IT d@ s-: a32 C+++>$ U*+ P++ L- E W++ N+(++) !o K- w----- !O M- !V PS+
PE Y+ PGP t++(-) 5+++ X++(-) R+ !tv b++ DI D-- G+ e+++*>++++ h-- r++>+++ y+
(Sexy, slow female voice:) oooOOOO, Greg's in... OOOOooo,
Greg's out... ooooOOOOO, Greg's in... OOOoooo, Greg's out...
ooooOOOOO, Greg's in... Humph, Greg's busy, you had better call
back later...
-- Answering machine madness - family fun
Reply to: