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
|
[[!meta copyright="Copyright © 2008, 2009 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="dtrace Support"]]
One of the main problems of the current Hurd implementation is very poor
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 profiling tools could be convieved, 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 framework for that is Sun's dtrace; but there might be others.
The student has to evaluate the existing options, deciding which makes most
sense for the Hurd; and implement that one. (Apple's implementation of dtrace
in their Mach-based kernel might be helpful here...)
This project requires ability to evaluate possible solutions, and experience
with integrating existing components as well as low-level programming.
Possible mentors: Samuel Thibault (youpi)
Exercise: In lack of a good exercise directly related to this taks, just pick
one of the kernel-related or generally low-level tasks from the bug/task
trackers on savannah, and make a go at it. You might not be able to finish the
task in a limited amount of time, but you should at least be able to make a
detailed analysis of the issue.
*Status*: Andei Barbu was working on
[SystemTap](http://csclub.uwaterloo.ca/~abarbu/hurd/) for GSoC 2008, but it
turned out too Linux-specific. He implemented kernel probes, but there is no
nice frontend yet.
|
