Some words on memory usage and low_resource_manager.
The idea is that there are two types of “used” memory. One part is used for somewhat permanent storage (say, an application heap and stack areas). Another part is used for caches (disk cache, file cache, etc). This second part is a bit different because it can be freed at any time if needed: you just need to flush the content of the area to disk (if it was modified) and you can reuse the memory pages for something else. This is what the low_resource_manager does: it keeps track of the memory usage, and decides to trim down these caches when needed.
So, what AboutSystem and other tools report is the memory usage ignoring these caches. Otherwise, people will complain that Haiku is a resource hog and uses all available memory (well, of course it does, it would be sad to leave it unused when we can make profit of it to have things run faster). So, we only report the non-easily-releasable part there to make people happy about how light and small Haiku is. It seems less confusing to them users.
The summary is: there is no single right answer to “how much memory is the system using?”
In ProcessController memory menu you can see this “easily releasable” memory shown in light blue I think.
(this does not exclude bugs in the memory accounting, which can also be improved. In the early days before alpha1 we had Haiku reporting negative memory usage in some cases…)
Well, mmap still requires the data to be cached in RAM at some point so that the code can access it as if it was memory. So, these areas can be removed at any time if needed, without flushing back to disk. It should be a pretty fast process. But it seems the low_resource_manager has trouble doing this and ends up using a lot of CPU. Maybe there is some inefficient algorithm there trying to scan all areas to see what can be released, or maybe it’s desperately looping over all areas, seeing that none can be flushed anywhere, but still the memory usage is too high?
Did you confirm that the font cache is the problem, or is it only a victim of something else in test_app_server actually using up all the available memory? I would search for a few very large areas, or a large number of areas with non-0 “alloc”, unless these areas with 0 reported alloc actually use up some pages?