X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/3ddaab8765c7fe9f1aa6cb388df73ff237fc9071..131c883489555ae200d5d3c02b7448731949c352:/doc/FAQ.doc

diff --git a/doc/FAQ.doc b/doc/FAQ.doc
index 5856a6122f..ecba2a42d1 100644
--- a/doc/FAQ.doc
+++ b/doc/FAQ.doc
@@ -680,7 +680,7 @@ of processes in your simulations.
      result in *fat* simulation hindering debugging.
    - It was really boring to write 25,000 entries in the deployment
      file, so I wrote a little script
-     <tt>examples/gras/tokenS/make_deployment.pl</tt>, which you may
+     <tt>examples/gras/mutual_exclusion/simple_token/make_deployment.pl</tt>, which you may
      want to adapt to your case. You could also think about hijacking
      the SURFXML parser (have look at \ref faq_flexml_bypassing).
    - The deployment file became quite big, so I had to do what is in
@@ -690,10 +690,24 @@ of processes in your simulations.
      user don't get into trouble about this. You want to tune this
      size to increse the number of processes. This is the
      <tt>STACK_SIZE</tt> define in 
-     <tt>src/xbt/context_private.h</tt>, which is 128kb by default.
+     <tt>src/xbt/xbt_ucontext.c</tt>, which is 128kb by default.
      Reduce this as much as you can, but be warned that if this value
      is too low, you'll get a segfault. The token ring example, which
-     is quite simple, runs with 40kb stacks.
+     is quite simple, runs with 40kb stacks.     
+   - You may tweak the logs to reduce the stack size further.  When
+     logging something, we try to build the string to display in a
+     char array on the stack. The size of this array is constant (and
+     equal to XBT_LOG_BUFF_SIZE, defined in include/xbt/log/h). If the
+     string is too large to fit this buffer, we move to a dynamically
+     sized buffer. In which case, we have to traverse one time the log
+     event arguments to compute the size we need for the buffer,
+     malloc it, and traverse the argument list again to do the actual
+     job.\n     
+     The idea here is to move XBT_LOG_BUFF_SIZE to 1, forcing the logs
+     to use a dynamic array each time. This allows us to lower further
+     the stack size at the price of some performance loss...\n
+     This allowed me to run the reduce the stack size to ... 4k. Ie,
+     on my 1Gb laptop, I can run more than 250,000 processes!
 
 \subsubsection faq_MIA_batch_scheduler Is there a native support for batch schedulers in SimGrid?
 
@@ -1117,15 +1131,20 @@ reason:
 
 \subsubsection faq_trouble_errors_big_fat_warning I'm told that my XML files are too old.
 
-We have decided to change the units in SimGrid. Now we use Bytes, Flops and
-seconds instead of MBytes, MFlops and seconds... Units should be updated
-accordingly and the version of platform_description should be set to a
-valuer greater than 1:
+The format of the XML platform description files is sometimes
+improved. For example, we decided to change the units used in SimGrid
+from MBytes, MFlops and seconds to Bytes, Flops and seconds to ease
+people exchanging small messages. We also reworked the route
+descriptions to allow more compact descriptions.
+
+That is why the XML files are versionned using the 'version' attribute
+of the root tag. Currently, it should read:
 \verbatim
-  <platform_description version="1">
+  <platform version="2">
 \endverbatim
-You should try to use the surfxml_update.pl script that can be found
-<a href="https://gforge.inria.fr/plugins/scmsvn/viewcvs.php/contrib/trunk/platform_generation/?rev=4721&root=simgrid"">here</a>.
+
+If your files are too old, you can use the simgrid_update_xml.pl
+script which can be found in the tools directory of the archive.
 
 \subsection faq_trouble_valgrind Valgrind-related issues