open_issues/gnumach_vm_map_entry_forward_merging: New, IRC.

1 files changed, 68 insertions, 0 deletions

diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn
new file mode 100644
index 00000000..58013021
--- /dev/null
+++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn
@@ -0,0 +1,68 @@
+[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_gnumach]]
+
+
+# IRC, freenode, #hurd, 2011-07-20
+
+    <braunr> could we add gnumach forward map entry merging as an open issue ?
+    <braunr> probably hurting anything using bash extensively, like build most
+      build systems
+    <braunr> mcsim: this map entry merging problem might interest you
+    <braunr> tschwinge: see vm/vm_map.c, line ~905
+    <braunr> "See whether we can avoid creating a new entry (and object) by
+      extending one of our neighbors.  [So far, we only attempt to extend from
+      below.]"
+    <braunr> and also vm_object_coalesce
+    <braunr> "NOTE:   Only works at the moment if the second object is NULL -
+      if it's not, which object do we lock first?"
+    <braunr> although map entry merging should be enough
+    <braunr> this seems to be the cause for bash having between 400 and 1000+
+      map entries
+    <braunr> thi makes allocations and faults slow, and forks even more
+    <braunr> but again, this should be checked before attempting anything
+    <braunr> (for example, this comment still exists in freebsd, although they
+      solved the problem, so who knows)
+    <antrik> braunr: what exactly would you want to check?
+    <antrik> braunr: this rather sounds like something you would just have to
+      try...
+    <braunr> antrik: that map merging is actually incomplete
+    <braunr> and that entries can actually be merged
+    <antrik> hm, I see...
+    <braunr> (i.e. they are adjacent and have compatible properties
+    <braunr> )
+    <braunr> antrik: i just want to avoid the "hey, splay trees mak fork slow,
+      let's work on it for a month to see it wasn't the problem"
+    <antrik> so basically you need a dump of a task's map to check whether
+      there are indeed entries that could/should be merged?
+    <antrik> hehe :-)
+    <braunr> well, vminfo should give that easily, i just didn't take the time
+      to check it
+    <jkoenig> braunr, as you pointed out, "vminfo $$" seems to indicate that
+      merging _is_ incomplete.
+    <braunr> this could actually have a noticeable impact on package builds
+
+
+# Procedure
+
+  * Analyze.
+
+  * Measure.
+
+  * Fix.
+
+  * Measure again.
+
+  * Have [[tschwinge]] measure with gcc build (currently needs 11 h).
+    [[tschwinge]] will in the mean time figure out the difference between using
+    bash and dash.
+
+  * Have Samuel measure on the buildd.