#5816: Kernel out of memory ---------------------------+------------------------------------------------ Reporter: axeld | Owner: bonefish Type: bug | Status: assigned Priority: normal | Milestone: R1/alpha3 Component: System/Kernel | Version: R1/Development Keywords: | Blockedby: Patch: 0 | Platform: All Blocking: 4963 | ---------------------------+------------------------------------------------ Comment(by bonefish): Some additional output in object_cache_low_memory() makes it clear what is happening: {{{ low resource address space: normal -> note object_cache_low_memory(): cache 0x82808d00: pressure: 356, empty: 0 object_cache_low_memory(): cache 0x828a1dc0: pressure: 397, empty: 2 object_cache_low_memory(): cache 0x828a6140: pressure: 2449, empty: 0 block_cache::_LowMemoryHandler(): 0xd1526000: unused: 10 -> 10 block_cache::_LowMemoryHandler(): 0x83023594: unused: 3 -> 0 block_cache::_LowMemoryHandler(): 0xd1526594: unused: 313434 -> 313384 block_cache::_LowMemoryHandler(): 0xd0921198: unused: 13 -> 0 object_cache_low_memory(): cache 0x82808d00: pressure: 356, empty: 0 object_cache_low_memory(): cache 0x828a1dc0: pressure: 397, empty: 9 object_cache_low_memory(): cache 0x828a6140: pressure: 2449, empty: 0 block_cache::_LowMemoryHandler(): 0xd1526000: unused: 3156 -> 3156 block_cache::_LowMemoryHandler(): 0x83023594: unused: 0 -> 0 block_cache::_LowMemoryHandler(): 0xd1526594: unused: 313054 -> 313004 block_cache::_LowMemoryHandler(): 0xd0921198: unused: 0 -> 0 object_cache_low_memory(): cache 0x82808d00: pressure: 356, empty: 3 object_cache_low_memory(): cache 0x828a1dc0: pressure: 397, empty: 141 object_cache_low_memory(): cache 0x828a6140: pressure: 2449, empty: 0 block_cache::_LowMemoryHandler(): 0xd1526000: unused: 0 -> 0 block_cache::_LowMemoryHandler(): 0x83023594: unused: 0 -> 0 block_cache::_LowMemoryHandler(): 0xd1526594: unused: 312768 -> 312718 block_cache::_LowMemoryHandler(): 0xd0921198: unused: 0 -> 0 }}} `ObjectCache::pressure` is only decreased when the low resource level reaches at least "warning" (which never happens during the test), so the empty slab counts have a fixed upper limit (e.g. 1225 for the source volume block cache). Reviewing the figures from the previous run, the slabs use less than 800 MB, BTW. Fragmentation of the slab areas might translate that to quite a bit more, but I guess the real problem is that the heap is continuously growing -- i.e. even if the slabs were drained completely, the address space limit would be hit eventually. It also doesn't help that heap and slab have different allocation backends (IOW that the slab allocator is not used as the heap). -- Ticket URL: <http://dev.haiku-os.org/ticket/5816#comment:8> Haiku <http://dev.haiku-os.org> Haiku - the operating system.