[Swift-commit] r3368 - text/parco10submission

[noreply at svn.ci.uchicago.edu]

Author: wozniak
Date: 2010-06-15 16:49:55 -0500 (Tue, 15 Jun 2010)
New Revision: 3368

Modified:
   text/parco10submission/paper.tex
Log:
Move FS notes


Modified: text/parco10submission/paper.tex
===================================================================
--- text/parco10submission/paper.tex	2010-06-15 21:44:50 UTC (rev 3367)
+++ text/parco10submission/paper.tex	2010-06-15 21:49:55 UTC (rev 3368)
@@ -837,24 +837,6 @@
 jobs) is delayed (in the worst case, activity dependant on the first job
 in a cluster must wait for all of the jobs to run).
 
-%%% Move this to Future Work
-
-%% \subsection{Avoiding filesystem inefficiency}
-
-%% When running a large number of jobs on a site at once, access to the
-%% shared filesystem on that site can be a bottleneck.
-
-%% On large systems, the shared file system is commonly provided by
-%% GPFS\cite{GPFS}. This can scale well but when used na\"ively can
-%% exhibit pathological behaviour. Early versions of Swift triggered this
-%% behaviour by targetting too much file system activity at a single
-%% working directory, so that GPFS lock contention came to dominate execution
-%% time.
-
-%% TODO more... - work done on arranging things in fs; presumably can
-%% forwardref collective IO section if that gets written, or include that
-%% entire section here?
-
 \subsection{Features to support use on dynamic resources}
 
 Using Swift to submit to a large number of sites poses a number of
@@ -1225,11 +1207,14 @@
 
 \subsection{Collective IO}
 
-  TODO: I don't actually grasp what is going on here (as in wtf is
-collective IO?), let alone what is going on that is "interesting", and
-would need a much better understanding of before I could write about it
-(let alone write about it in relation to Swift)
+%% On large systems, the shared file system is commonly provided by
+%% GPFS\cite{GPFS}. This can scale well but when used na\"ively can
+%% exhibit pathological behaviour. Early versions of Swift triggered this
+%% behaviour by targetting too much file system activity at a single
+%% working directory, so that GPFS lock contention came to dominate execution
+%% time.
 
+
 \subsection{Language development}
 
   TODO: describe how it becomes more functional as time passes, as is