summaryrefslogtreecommitdiff
path: root/open_issues/gnumach_memory_management.mdwn
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@codesourcery.com>2013-04-24 11:53:02 +0200
committerThomas Schwinge <thomas@codesourcery.com>2013-04-24 11:53:02 +0200
commit6da9bd33a5137bad9003f1f9017959efeead5fc6 (patch)
tree953757cb78af2c5904722103436d9b3c3b99d686 /open_issues/gnumach_memory_management.mdwn
parentc33556ffa02309a145a65400a270cd991d70a896 (diff)
parent6b366a25f9fd496777ff42932685924eb83696fc (diff)
Merge remote-tracking branch 'fp/master'
Diffstat (limited to 'open_issues/gnumach_memory_management.mdwn')
-rw-r--r--open_issues/gnumach_memory_management.mdwn34
1 files changed, 34 insertions, 0 deletions
diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn
index 511d3f2b..60ec7357 100644
--- a/open_issues/gnumach_memory_management.mdwn
+++ b/open_issues/gnumach_memory_management.mdwn
@@ -2229,3 +2229,37 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task.
<braunr> (i mean, when i made my tests, it looked like there were few
kernel map entries, but i may have missed corner cases that could cause
more of them to be needed)
+
+
+# IRC, freenode, #hurd, 2013-04-18
+
+ <braunr> oh nice, i've found a big scalability issue with my slab allocator
+ <braunr> it shouldn't affect gnumach much though
+
+
+## IRC, freenode, #hurd, 2013-04-19
+
+ <ArneBab> braunr: is it fixable?
+ <braunr> yes
+ <braunr> well, i'll do it in x15 for a start
+ <braunr> again, i don't think gnumach is much affected
+ <braunr> it's a scalability issue
+ <braunr> when millions of objects are in use
+ <braunr> gnumach rarely has more than a few hundred thousands
+ <braunr> it's also related to heavy multithreading/smp
+ <braunr> and by multithreading, i also mean preemption
+ <braunr> gnumach isn't preemptible and uniprocessor
+ <braunr> if the resulting diff is clean enough, i'll push it to gnumach
+ though :)
+
+
+### IRC, freenode, #hurd, 2013-04-21
+
+ <braunr> ArneBab_: i fixed the scalability problems btw
+
+
+## IRC, freenode, #hurd, 2013-04-20
+
+ <braunr> well, there is also a locking error in the slab allocator,
+ although not a problem for a non preemptible kernel like gnumach
+ <braunr> non preemptible / uniprocessor