(no commit message)
[ikiwiki.git] / docs / developer / SimonsTODOs.mdwn
1 ## Stuff 
2
3
4
5
6 * Import GDB 6.8
7
8
9 ## HAMMER
10
11 * Better on-disk placement to reduce seek times
12
13 * "Free copies" - cache recently read/written block CRCs, on write check CRC and on match verify that the blocks
14   are the same.  Then just create a btree link to the original data.  This could also be done in a hammer cleanup
15   pass, effectively de-duplicating the file system.
16
17
18 ## Memory Management (Kernel) 
19
20
21
22 Overal goal:  reduce malloc() use and replace with object cache allocations.  This should increase performance.
23
24
25
26
27 * Make free() nonblocking.  At the moment a call to free() might block because it might need to
28
29   aquire the BGL and maybe needs to wait for other locks (needs to be checked).
30
31
32
33   This allows us to use free() with dragonfly matching semantic, i.e. it can be used in critical sections
34
35   or with a spinlock held/in an interrupt.
36
37
38
39   For this to work, we need to:
40
41
42
43
44 * push locking into vm_map_* routines
45
46
47
48
49 * make sure no code path from free() might need to block
50
51
52
53
54
55
56 * polish up the objcache to work like bonwick described it, most important:  make magazines adjust
57
58   their size depending on depot lock contention
59
60
61
62
63 * implement a real slab allocator (bonwick) and switch the objcache to use it.  It could us
64
65   per-cpu (not so good, i think) or per-numa-cluster slabs, but in the beginning it for sure is possible
66
67   to use one slab for all, as most allocations should be satisfied by the objcache (and be serialized
68
69   anyways already by the depot lock)
70
71
72
73
74 * find and change code paths assuming power-of-2 allocations are power-of-2 allocated
75
76
77
78
79 * switch malloc() and free() to use the objcache for reasonable sized allocations
80
81   use kmem for larger ones
82
83
84
85 ## Bootup 
86
87
88
89 Investigate why the system does not boot within one second.  I have a fast box, this should be possible.  Somewhere are delays adding up.  Maybe use kernel threads for probing/initialisation.
90
91
92
93 ## Profiling 
94
95
96
97 Port [pmc](http://people.freebsd.org/~jkoshy/projects/perf-measurement/) (and maybe something like oprofile), so that we can find problematic areas.
98