#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: | ---------------------------+------------------------------------------------ Changes (by bonefish): * owner: axeld => bonefish * status: new => assigned Comment: I've also run into this during the last few days while testing PAE on a box with 4 GB RAM. After a `dd if=/dev/zero of=tt bs=1M count=3500` I started copying two haiku trees (with objects, weighing in at about 3.6 GB) from one partition to another. The copy process started relatively slow -- 2 to 3 MB/s -- and after a while dropped to abysmally slow -- < 100 KB/s. I didn't always let the copy process run on, but twice I let it run until it hit the out of memory panic. The syslog said pretty much the same as in the previous comment: The slab and heap would grow until the heap grower failed to allocate new areas. The reason being lack of address space in my case and apparently in the above one, too. As can be seen in the output, the slab allocations stop at some point -- probably when the address space low resource state reaches "note" and the block cache stops allocated new blocks -- and only the heap continues to grow -- probably for vnodes and related structures. That is suboptimal already -- currently the kernel favors vnodes over block cache over file cache. Still it doesn't explain why slab areas aren't freed at some point. At low resource state "critical" the block cache should go all out and throw away lots of blocks. Also, that doesn't explain the amazingly poor copying performance. Will try to analyze a bit. -- Ticket URL: <http://dev.haiku-os.org/ticket/5816#comment:3> Haiku <http://dev.haiku-os.org> Haiku - the operating system.