Re: amiboot - tlsfmem
Interesting.
I was able to complete an install of debian3.1 just a few hours ago,
it was a rather painful process, so i'll be looking into improving
that, hopefully.
2009/1/6 Chris Hodges <chrisly@platon42.de>:
> 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: