(no commit message)
[ikiwiki.git] / docs / developer / researchprojectspage / index.mdwn
index db01aa6..5e87abe 100644 (file)
@@ -12,15 +12,17 @@ Please feel free to add projects to this page, or annotate existing project idea
 * Well defined kernel build mechanisms for code generation
 * This will require discussion
 
-### On-disk / Over-the-wire structure codegen
+### On-disk / Over-the-wire structure codegen + CAPS
 * Somewhat analogous to google protocol buffers / etc.
-* Take a normalized definition of data, metadata, an operation and generate a structure, serialization routines and accessor routines for it/them
+* Take a normalized definition of data, metadata or an operation and generate a structure, serialization routines and accessor routines for it/them
 * Must be able to generate structs binary compatible with existing on-disk formats (including warts)
 * Should magically create formats that are 32/64bit agnostic OR fixup serializers/unserializers
 * Accessor routines and thread safety? Do we make you hang these objects somewhere that you store your synchronization objects or allow you to include them?
-* Versioning?
+* Optional versioning?
 * Potential uses: ... HAMMER, UFS, HAMMER mirror streams, message passing, ...
-* QUESTIONS: Would people actually use them?
+* CAPS (DragonFly's message passing system, which exists but is not functional at the time of this writing) has an over-the-wire format with serialization/deserialization. This codegeneration serialization solution should be amenable to the purposes of CAPS or whatever future message passing infrastructure might be implemented in DragonFly.
+* CAPS References: [1](http://www.shiningsilence.com/dbsdlog/2003/11/25/139.html#more-139) [2](http://www.shiningsilence.com/dbsdlog/2004/03/07/293.html#more-293) [3](http://www.shiningsilence.com/dbsdlog/2004/04/24/365.html#more-365)
+* Messaging References: [1](http://leaf.dragonflybsd.org/mailarchive/commits/2006-07/msg00172.html)
 
 ### Asynchronous system call framework
 * Probably best implemented as a message passing interface to kernel pass messages in, threads pick them up and execute, return through kevent notifications
@@ -38,6 +40,23 @@ Please feel free to add projects to this page, or annotate existing project idea
 * Dispatch to the most efficient allocator implementation on future execution.
 * Perhaps allocators can export their size range and a series of flags indicating what they are suited for, and the profiling could build a set of flags based on application behavior.
 * This could be done per-thread in a lockless fashion and coalesced with weights atexit().
-* The scope of this work might be appropriate for a PhD or Masters thesis.
+* The scope of this work might be appropriate for a thesis.
 * Such a framework likely would not replace the base system allocator but if it were lightweight enough could possibly augment (and/or incorporate) it.
 * For applications definitely known to work better under some configuration, flags could be seeded and pkgsrc could link those apps against the best alternative meta-allocator.
+
+### Opt-in userland thread scheduler
+* A great deal of research has been done on this topic, implementations exist for other operating systems.
+* References: [1](http://leaf.dragonflybsd.org/mailarchive/kernel/2007-03/msg00038.html)
+
+### Make the use of XIO pervasive
+* XIO could be applied liberally to the I/O stack
+* Determine the best use cases for XIO and create a list of paths to target.
+* Slog through the identified kernel paths converting existing I/O magic to XIO.
+* References: [1](http://www.shiningsilence.com/dbsdlog/2004/03/30/331.html#more-331)
+
+### Evaluate/Improve Context Switching Performance
+* When a context switch happens, both the virtually tagged L1
+  cache and non-tagged TLB have to be flushed.
+* How expensive is this flushing of those caches, taking into
+  account how many cycles are spent in reloading the cache.
+* Small-Address Spaces [1](http://www.l4ka.org/publications/2002/smallspaces.pdf) could overcome this context switch cost by multiplexing the virtual address space using segmentation.