summaryrefslogtreecommitdiff
path: root/community/gsoc
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@codesourcery.com>2013-03-26 15:49:59 +0100
committerThomas Schwinge <thomas@codesourcery.com>2013-03-26 15:49:59 +0100
commit7c90e65e25f673a9c621c6102ee3d7c130160b01 (patch)
treeb399b10e23f3194d70326eac190f74de473d60d5 /community/gsoc
parentab11a8b78ca03dede4b29bbb7a04dac40019042f (diff)
parent6ded0f6763c776e42d363f2b5714c79a34c9b70f (diff)
Merge commit '6ded0f6763c776e42d363f2b5714c79a34c9b70f'
Polish and enhance some pages some more.
Diffstat (limited to 'community/gsoc')
-rw-r--r--community/gsoc/project_ideas.mdwn4
-rw-r--r--community/gsoc/project_ideas/object_lookups.mdwn42
2 files changed, 45 insertions, 1 deletions
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index d235570f..5a274cc5 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -83,10 +83,12 @@ other: language_bindings, gccgo, perl_python. -->
[[!inline pages="community/gsoc/project_ideas/language_bindings" show=0 feeds=no actions=yes]]
[[!inline pages="community/gsoc/project_ideas/virtualization" show=0 feeds=no actions=yes]]
[[!inline pages="community/gsoc/project_ideas/file_locking" show=0 feeds=no actions=yes]]
+[[!inline pages="community/gsoc/project_ideas/object_lookups" show=0 feeds=no actions=yes]]
[[!inline pages="community/gsoc/project_ideas/server_overriding" show=0 feeds=no actions=yes]]
[[!inline pages="community/gsoc/project_ideas/tcp_ip_stack" show=0 feeds=no actions=yes]]
[[!inline pages="community/gsoc/project_ideas/nfs" show=0 feeds=no actions=yes]]
-[[!inline pages="community/gsoc/project_ideas/smp" show=0 feeds=no actions=yes]]
+<!-- Richard, This task actually looks too big for a GSoC project.
+[[!inline pages="community/gsoc/project_ideas/smp" show=0 feeds=no actions=yes]] -->
[[!inline pages="community/gsoc/project_ideas/sound" show=0 feeds=no actions=yes]]
[[!inline pages="community/gsoc/project_ideas/disk_io_performance" show=0 feeds=no actions=yes]]
[[!inline pages="community/gsoc/project_ideas/vm_tuning" show=0 feeds=no actions=yes]]
diff --git a/community/gsoc/project_ideas/object_lookups.mdwn b/community/gsoc/project_ideas/object_lookups.mdwn
new file mode 100644
index 00000000..462f6a12
--- /dev/null
+++ b/community/gsoc/project_ideas/object_lookups.mdwn
@@ -0,0 +1,42 @@
+[[!meta copyright="Copyright © 2013 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="Improved system object lookups"]]
+
+The Hurd currently uses its ihash library ([[hurd/libihash]]) as a generic
+container for various objects. While it does its job, it has been reported
+to suffer from high collision rates. In addition, the "one size fits all"
+approach contributes to slow things down. One particular use case is looking
+up an object from a Mach port name, which basically translates to getting the
+file or socket associated with a file descriptor in traditional Unix systems.
+It's particular because there are actually two lookups for each object, the
+first being finding the Mach port from a client port name, which is done in
+the GNU Mach kernel, and the second being finding the server object from a
+server port name. The best strategy would probably be to directly associate
+the address of an object to the receive right of its port, eliminating the
+need to look up again, but this is quite an intrusive change in the code base.
+For the time being, optimizing lookups would already be an improvement.
+
+The goal of this project is to increase system performance by speeding up
+object lookups, with a particular focus on name-to-object lookups. Note that
+there is little room for improvement in the kernel name-to-port lookups because
+of the various optimizations IPC has received in the past. Looking up server
+objects from port names could use an algorithm highly tuned for this task,
+perhaps with better locking (shared/exclusive instead of always mutually
+exclusive for example). Then, the libihash algorithm could be replaced with a
+better one, not necessarily a hash based one, to improve all the other users.
+
+This task requires proper knowledge of data structure algorithms, taking into
+account machine properties such as processor caches, as well as the appropriate
+skills in C and assembly to check the generated code. Being able to perform
+accurate measurements in a system that lacks modern profiling tools would also
+be helpful.
+
+Possible mentors: Richard Braun