1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
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.
|
