[haiku-development] Re: heap freelist problem?
- From: "Michael Lotz" <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 03 Feb 2008 16:48:17 +0100
Hi Jonas
> Do the the freelists ever get cleaned up/emptied? Is memory
> fragmentation and bad cache performance the root cause of the
> performance drop I'm seeing?
Well, the large free lists by themselfs aren't a problem. That's just
how the allocator currently works (it'll be replaced sooner or later).
When something gets allocated then the allocator will first check if it
still has space by checking the freelist. If it finds something in
there then it will just remove the address from the freelist and then
return that (well, that's a bit simplified ;-). When it doesn't have
anything in the freelist it will allocate some more pages for this bin.
When freeing an address it basically just pushes the address into the
freelist and is done. It would be possible to check if a whole chunk is
now in the freelist and all the allocated pages could be freed now, but
this would require some algorithms I doubt will be implemented since
the allocator is going to be replaced anyway...
Still what you've discovered is exactly the cause for the system
becoming slow! Since we currently have quite a bit of debug helpers
active, our heap does a bit more than necessary. It overwrites all
freed memory with "0xdeadbeef" so it's easy to tell when someone tries
to use freed memory (not really a performance problem). But it also
does check the free list for a double call of free by iterating over
all the freelist entries (src/system/kernel/heap.c:623). Now when the
freelists grow bigger, the time for each free will increase by quite a
bit. As there are lots of small allocs and frees happening all the
time, this bring down the performance of the whole system considerably.
Now the question is what to do. Should we disable that debug code or
should we try to improve the performance somehow?
Regards
Michael
Other related posts:
