Quoting Justus Winter (2015-02-24 17:15:22)
Quoting Samuel Thibault (2015-02-24 01:04:19)
I tried to start a gcc-5 build, it gets stuck at the tar x stage, with
gnumach printing:
no more room for vm_map_find_entry in 80223e20 (kmem_map_store)
no more room for kmem_realloc in 80223e20 (kmem_map_store)
[...]
ipc_port 0010 80 4k50 262239 262350 20988k
0k
kmem_realloc is only used to enlarge the ipc tables, but this is not
due to the lack of space, but due to the lack of a sufficiently large
continuous chunk of the kernel address space.
As demonstrated by the attached program the maximum number of ports a
task can have seems to be around 25, which doesn't seem like a
lot.
% ./test
./test: mach_port_allocate (last good name: 242175): (os/kern) resource
shortage
This suggests that we need a different data structure that doesn't
depend on a continuous chunk of memory.
I have replaced the IPC tables (and the reverse hash tables, which
were intertwined with the tables) with radix trees. It seems to be
working, but it needs some more cleanups, commit messages, and some
adjustments of the debug interface (which I assume I can change
freely, right?). The patches are here:
http://darnassus.sceen.net/gitweb/teythoon/gnumach.git/shortlog/refs/heads/ipc-radix-trees-3
I haven't had a chance to assess the performance impact.
This change raises the number of ports that a task can allocate to
~95. Unfortunately, if the kernel runs out of space, it now
simply crashes instead of returning KERN_NO_SPACE.
Here are the relevant parts of /proc/slabinfo, before the allocation
of 95 ports and after that:
root@debian:~# head -n1 /proc/slabinfo
cache obj slab bufs objs bufstotal reclaimable
root@debian:~# egrep 'ipc_entry|rdxtree_node' /proc/slabinfo
rdxtree_node 0010 280 4k14 2995 3108 888k 24k
ipc_entry 0010 16 4k 254 4231 4572 72k 4k
root@debian:~# egrep 'ipc_entry|rdxtree_node' /proc/slabinfo
rdxtree_node 0010 280 4k14 18151 182005200k 12k
ipc_entry 0010 16 4k 254 954283 954532 15032k 0k
Cheers,
Justus
