From 2bc136e680877b6a9d17d6a0e815b47775088d67 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 9 May 2011 10:47:56 +0200 Subject: IRC. --- open_issues/rework_gnumach_ipc_spaces.mdwn | 77 ++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) (limited to 'open_issues/rework_gnumach_ipc_spaces.mdwn') diff --git a/open_issues/rework_gnumach_ipc_spaces.mdwn b/open_issues/rework_gnumach_ipc_spaces.mdwn index 5bf0c530..b7cda227 100644 --- a/open_issues/rework_gnumach_ipc_spaces.mdwn +++ b/open_issues/rework_gnumach_ipc_spaces.mdwn @@ -10,6 +10,14 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] +IRC, freenode, #hurd, 2011-05-07 + + things that are referred to as "system calls" in glibc are + actually RPCs to the kernel or other tasks, those RPCs have too lookup + port rights + the main services have tens of thousands of ports, looking up one + is slow + There is a [[!FF_project 268]][[!tag bounty]] on this task. IRC, freenode, #hurd, 2011-04-23 @@ -241,3 +249,72 @@ IRC, freenode, #hurd, 2011-04-23 so a radix ree would be the most efficient well, if some processes really feel they must use random numbers for port names, they *ought* to be penalized ;-) + +2011-04-27 + + antrik: remember when you asked why high numbers would be a + problem with radix trees ? + here is a radix tree with one entry, which key is around 5000 + [ 656.296412] tree height: 3 + [ 656.296412] index: 0, level: 0, height: 3, count: 1, + bitmap: 0000000000000002 + [ 656.296412] index: 1, level: 1, height: 2, count: 1, + bitmap: 0000000000004000 + [ 656.296412] index: 14, level: 2, height: 1, count: 1, + bitmap: 0000000000000080 + three levels, each with an external node (dynamically allocated), + for one entry + so in the worst case of entries with keys close to the highest + values, the could be many external nodes with higher paths lengths than + when keys are close to 0 + which also brings the problem of port name allocation + can someone with access to a buildd which has an uptime of at + least a few days (and did at least one build) show me the output of + portinfo 3 | tail ? + port names are allocated linearly IIRC, like PIDs, and some parts + of the kernel may rely on them not being reused often + but for maximum effifiency, they should be + efficiency* + 00:00 < braunr> can someone with access to a buildd which has an + uptime of at least a few days (and did at least one build) show me the + output of portinfo 3 | tail ? + :) + it's almost like wc -l + 4905: receive + vs 4647 + for / + 52902: receive + vs 52207 + for the chroot + even after several builds ? + and several days ? + that's after 2 days + it's not so many builds + rossini is not so old + (7h) + but many builds + 70927: send + vs 70938 + ok + so it seems port names are reused + good + yes they are clearly + i think i remember a comment about why the same port name + shouldn't be reused too soon + well, it could help catching programming errors + that it helped catch bugs in applications that could + deallocate/reallote quickly + reallocate* + without carefuly synchronization + careful + damn, i'm tired :/ + but that's about debugging + so we don't care about performance there + yes + i'll try to improve allocation performance too + using e.g. bitmaps in each external node back to the root so that + unused slots are quickly found + i thknk that's what idr does in linux + braunr: idr? + antrik: a data structure used to map integers to pointers + http://fxr.watson.org/fxr/source/lib/idr.c?v=linux-2.6 -- cgit v1.2.3