[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: