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

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.



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: