community/gsoc/project_ideas/dtrace -> open_issues/dtrace.

2 files changed, 48 insertions, 1 deletions

diff --git a/open_issues/dtrace.mdwn b/open_issues/dtrace.mdwn
new file mode 100644
index 00000000..1931f340
--- /dev/null
+++ b/open_issues/dtrace.mdwn
@@ -0,0 +1,47 @@
+[[!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]]."]]"""]]
+
+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 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 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)
+
+Related: [[LTTng]]
+
+Exercise: In lack of a good exercise directly related to this task, 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.
diff --git a/open_issues/profiling.mdwn b/open_issues/profiling.mdwn
index c8774f07..1aba698c 100644
--- a/open_issues/profiling.mdwn
+++ b/open_issues/profiling.mdwn
@@ -17,7 +17,7 @@ done for [[performance analysis|performance]] reasons.
     Should be working, but some issues have been reported, regarding GCC spec
     files.  Should be possible to fix (if not yet done) easily.
 
-  * [[community/gsoc/project_ideas/dtrace]]
+  * [[dtrace]]
 
     Have a look at this, integrate it into the main trees.