SLOW '05 is the premier workshop for papers to about computer systems, especially if you are taking the graduate operating systems course here at the University of Wisconsin with Remzi, and he is making you submit your paper to this thing, and if you don't, you know you'll get a D or maybe a C at best.
The 2005 SLOW workshop seeks unoriginal and highly non-innovative papers about the applications, architecture, implementation, and performance of computing systems. Or really, papers about things that interest Remzi. Some topics of interest include:
Continuous Profiling in LinuxPapers on all other topics will be rejected.
Adding Parity Protection to the Linux Ext3 File System
Exploring I/O in a Virtual Machine Environment
Fault Injection under the SGI XFS File System
Thread Detection in a Virtual Machine
Smarter NFS Server Caching with Semantic Inference
Memory Faults: Injection and Solutions
Memory Sharing in Virtual Machines
SCSI-based Fault Injection
IDE-based Fault Injection
Energy-Awareness in the Linux Virtual Memory Manager
An NFS Text-Searching Proxy
Lazy Logical Volume Management with Dada
Reviewing of full papers will be done by the SLOW program committee, which consists of me (Remzi). Papers must use a typeface no smaller than 10 point, and be no longer than ten (10) 8.5" by 11" pages including everything EXCEPT references (text and figures must fit onto 10 pages, but references can go on additional pages).
All papers must be submitted as PDF.
Title and Author List: should be self-evident.One good way to structure a paper is to find a paper you liked in class and copy its structure (loosely).
Abstract: Describe in short what you do, how you do it, and the results.
Introduction: Spend a little more time. Motivate the problem. Start with generalities, and narrow in on your problem. Describe your approach. What is good about it? Potential weaknesses? Summarize results. Give an outline of the rest of the paper.
Related Work: Write about other similiar work. What is different than what you did? What is similar? Try to draw general conclusions about what others have missed.
Description of what you did/built: Use pictures and words to show what you did. Be detailed. Think about how to organize what you are doing.
Results: Graphs and tables, all clear and understandable. Full description of each experiment and the results. What is the point of each graph? What conclusions can you draw from it?
Conclusions: Appropriately drawn from the work described, as general as possible, with a hint of "lessons learned"; what did you get out of the study? Summary is what you did; conclusions are what you learned.
If you plan on using latex (which is great for this sort of thing), click
here for an example Latex template
(in tar format). If you plan on using MS Word (though why would you?), please make sure you know how to generate PDF.
Authors of all papers will be expected to provide an
to their paper, and to the
described in their paper. Papers, software, and data will all be collected for inclusion in an electronic version of the symposium.