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
|
[[!meta copyright="Copyright © 2008, 2009, 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]]."]]"""]]
[[!meta title="Kernel Instrumentation"]]
[[!tag open_issue_gnumach]]
One of the main problems of the current Hurd implementation is very poor
[[open_issues/performance]]. While we have a bunch of ideas what could cause the performance
problems, these are mostly just guesses. Better understanding what really
causes bad performance is necessary to improve the situation.
For that, we need tools for performance measurements. While all kinds of more
or less specific [[open_issues/profiling]] tools could be conceived, the most promising and
generic approach seems to be a framework for logging certain events in the
running system (both in the microkernel and in the Hurd servers). This would
allow checking how much time is spent in certain modules, how often certain
situations occur, how things interact, etc. It could also prove helpful in
debugging some issues that are otherwise hard to find because of complex
interactions.
The most popular kernel instrumentation framework is Sun's dtrace,
originally written for Solaris,
but also adopted by some other systems.
However, the GPL-incompatible license means it can't be used in Linux,
and thus Linux developers created their own frameworks instead:
first [[SystemTap]], and now [[LTTng]].
In 2008, Andrei Barbu did initial work on kernel probes for the Hurd.
However, not all of his patches got merged,
because some turned out not to be fully functional.
Also, he didn't get around to work on userspace probes,
nor on a nice frontend for writing test scripts employing the probes.
The goal of this project is to make the instrumentation framework
more usable and complete,
and to better integrate it in the Hurd.
For that, the student will have to work
on some real profiling and/or debugging tasks,
and fix any shortcomings he encounters in the framework.
This is a pretty involved task.
Previous experience with low-level programming is a must;
and it also requires a good grasp on interactions in complex systems.
To work on this project,
the student will have to get familiar with GNU Mach.
(The microkernel employed by the Hurd.)
Some understanding of other aspects of the Hurd will also be required,
depending on the exact nature of the profiling/debugging performed.
Possible mentors: Samuel Thibault (youpi)
Exercise: Use the existing probes to perform some simple measurement.
|
