FreeLists / haiku-development / [haiku-development] Re: Latest changes and general status.

[Bruno Albuquerque <bga@xxxxxxxxxxxxx>]

Axel Dörfler wrote:

> Actually, that doesn't have to mean anything. For example, all slabs 
> are counted to normal memory as well - and that's what the block cache 
> is using. Since the slabs are deallocated lazily, the memory is not 
> freed when it could be freed, but only when someone needs to free it 
> (ie. when memory is low).
So I did a simple test: I ran "unzip haiku_src.zip; rm -rf haiku_src" in 
an infinite loop. Eventually I ran out of memory. Even taking into 
account what you said above, this should not happen at all.
> So while we need a better mechanism to track committed vs. cached 
> memory (the slab is tricky, though, as one might not be able to flush 
> all of them even under memory pressure when some blocks are still in 
> use), it doesn't necessarily mean there is a memory leak somewhere.
But do we know how much memory is being used in a slab? because it that 
memory can be reused (and I guess it can) we just need to also track 
this and report whatever is available as free memory. Or am I missing 
something?
> Anyway, I think there is actually a leak in the network stack (or 
> rather, TCP), but unzipping anything surely shouldn't trigger it :-)
I sure hope this is the case. If unzippig a local file causes TCP to 
leak we are probably in a really bad shape. ;)
> To see where the memory is spent on, you can dig in the KDL a bit, the 
> area/heap debugger commands are surely helpful with that.
Will try that later today when I get home.

-Bruno