DO YOU HAVE A PROBLEM?
----------------------

 Use the included AvailFrag and FragMeter programs or a system monitor
such as Scout or XOper to determine if your system memory list has
many small holes of 8 to 256 bytes each. Lots of small chunks are
usually made by badly written programs (not freeing all the memory
they allocated).


WHY IS THAT BAD?
----------------

 A memory list containing hundereds of small nodes slows down the
system because each time AllocMem() or FreeMem() get called
(which happens VERY frequently) the memory list must be scanned
until a suitable chunk is found.


WHO IS CAUSING IT?
------------------

 On systems equipped with 68040 or 68060 the program SetPatch will
load the 68060.library  68040.library at boot time. These libraries
will setup the MMU page descriptors to cover all addressable memory
space, including space reserved by Zorro boards. Unfortunately, the
040/060 MMUs requires an 512-byte alignament for the page descriptors,
even if they take up just 256 bytes. So the libraries free up the
remaining 256 bytes in order to give some memory back to the system.
On my Amiga 4000, fitted with four Zorro boards, this creates more
than 500 memory chunks right after booting the system! Such a
fragmented memory list will slow down all AllocMem() and FreeMem()
calls as they need to scan almost the entire list before they can
reach the first memory chunk bigger than 256 byte. You can test
the impact of the memory list fragmentation on your system by
copying a very big file to RAM: before and after SetPatch.


IS THERE A SOLUTION?
--------------------

 Luckly, the 68040/68060 library that comes with the nice
mmu.library package by Thomas Richter is not affected by the problem
desribed above. Also the V44 version of the 68040.library which is
distributed with AmigaOS 3.5 has been fixed not to create so many
small holes in the memory list.


WHAT ELSE IS CAUSING PROLEMS?
-----------------------------

 Even with these new 68040 libraries, many Amiga systems (my own
included) are still suffering by lots of 8 bytes chunks in the memory
list. On my system, I have over 100 frags after booting, and they
grow up to 200-300 when the system runs for some time. I still don't
know exactly what is causing this. The CatchFrags program installs
a patch to AllocMem() and FreeMem() to detect programs allocating
small memory chunks and report them on the debug console. Using it
I noticed that the input.device does many allocations of 8 bytes,
freeing them in a suspicious order. If you're clever enough, please
try to discover why it does so and if it can be patched to work
differently.


WHAT ELSE CAN YOU DO?
---------------------

 If your system is still affected by this problem, put AllocFrags
anywhere in your Startup-Sequence, after SetPatch. It will remove from
the memory list any chunks whose size is equal or smaller than 256 bytes.
Using AllocFrags frequently during your normal system activity is not
a good idea since it might cause even more fragmentation in your memory
list once you close a program and it frees a memory block which was
contiguous to one already removed by AllocFrags.

 I admit AllocFrags is a real hack and it WILL stop working when
the OS memory allocation engine is changed (e.g.: to accomodate
virtual or protected memory). Anyway, I'm sure that AllocFrags will
not cause any incompatibilities or system crashes on the current
OS versions upto OS 3.5. Inspect the source code if you don't
believe me.

 PERMSSN    UID  GID    PACKED    SIZE  RATIO     CRC       STAMP          NAME
---------- ----------- ------- ------- ------ ---------- ------------ -------------
[generic]                  271     284  95.4% -lh5- 6112 Oct 17  1999 AllocFrags/AllocFrags
[generic]                  773    1677  46.1% -lh5- 8c20 Oct 17  1999 AllocFrags/AllocFrags.c
[generic]                 1795    3722  48.2% -lh5- bed7 Dec  6  1999 AllocFrags/AllocFrags.readme
[generic]                  446     970  46.0% -lh5- fa7f Oct 12  1997 AllocFrags/AllocFrags.¶
[generic]                  648     932  69.5% -lh5- 940a Jan 30  1997 AllocFrags/AvailFrag
[generic]                  415     596  69.6% -lh5- 5d8b Oct 18  1999 AllocFrags/CatchFrags
[generic]                  816    2398  34.0% -lh5- 8db2 Oct 18  1999 AllocFrags/CatchFrags.c
[generic]                 2655    8918  29.8% -lh5- 504b Oct 17  1999 AllocFrags/CompilerSpecific.h
[generic]                 3947    5932  66.5% -lh5- 9bdc Oct 10  1999 AllocFrags/FragMeter
[generic]                  229     434  52.8% -lh5- 3033 Oct 17  1999 AllocFrags/SCOPTIONS
[generic]                  165     285  57.9% -lh5- 7f71 Oct 17  1999 AllocFrags/SMakefile
---------- ----------- ------- ------- ------ ---------- ------------ -------------
 Total        11 files   12160   26148  46.5%            Dec  6  1999