Conclusions for performance loss.

[loba.git] / BUGS

diff --git a/BUGS b/BUGS
index 5d493adbba62676426fa8571d67bc87dc0281733..5fd633b52cc6cb8d24fc4d8443e4c5fb49eb0720 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -1,20 +1,99 @@
-Faut-il protéger les accès concurrents à real_load, entre compute_loop
-et load_balance_loop ?
+========================================================================
+-- Wed, Feb 29 16:16:45 2012 +0100
+
+Les exécutions parallèles donnent des résultats différents.
+Pourquoi ?
+
+========================================================================
+##### MOSTLY RESOLVED BUGS COME AFTER THIS #############################
+========================================================================
+-- Wed, 02 May 2018 10:48:05 +0200
+
+Fort ralentissement d'un facteur 2, voire plus, avec les versions récentes de
+SimGrid (3.18, 3.19.1).  Il semblerait que l'utilisation d'exceptions en cas de
+timeout dans les simcalls soit coûteuse. À vérifier.
+
+-- Mon, 07 May 2018 16:05:49 +0200
+
+Les exceptions ne sont plus utilisées depuis le commit
+8efeb3a6aa2c201800a3ba19416ea9728af3bff6 (Stop using costly exceptions on
+timeout for simix synchros).
+
+Le ralentissement restant dans lmm_solve() semble venir essentiellement du
+commit f3677661714bf6122d678071c0bd44141417be14 (Fix bug #17132 (surf.c:366: The
+Impossible Did Happen (yet again))).
+
+========================================================================
+-- Wed, 02 May 2018 10:44:41 +0200
+
+Ne fonctionne pas avec les versions de SimGrid de 3.8 à 3.12 inclus : la
+simulation ne démarre pas (le thread "compute" déployé automatiquement n'est pas
+exécuté).
+
+Le problème est introduit par le commit e6d1ca27d8852f9922141ea15eae6b339c2d2bc7
+(Completely remove surfxml_callback. Clean the way to create arg for the
+process.), puis corrigé par le commit bb66fe3993929c5d1b25e4982502869d725cefd7
+([platf] Kill sg_process_cb).
+
+Avec des versions plus récentes, plante après la fin de la simulation (SIGSEGV)
+pour les versions de SimGrid de 3.13 à 3.17 inclus.
+
+========================================================================
+-- Mon, Feb 27 13:26:08 2012 +0100
+
+Les variables globales process::total_load_* ne sont pas protégées
+contre les accès concurrents.  Il n'est donc pas possible actuellement
+d'exécuter les simulations en parallèle (--cfg=contexts/nthreads).
+
+-- Wed, Feb 29 15:54:31 2012 +0100
+
+Corrigé en partie.  Il reste quelques "fixme: get locked?" à régler
+(ou pas).

 
 ========================================================================
 
 ========================================================================

-Il semblerait qu'il y ait un bug dans SG 3.5, et qu'on ne puisse pas
-utiliser MSG_comm_waitany() pour l'émetteur *et* le récepteur sans
-risquer d'interblocage.
+-- Fri, May 20 17:01:33 2011 +0200
+
+Il faut réviser l'utilisation du mutex entre le thread d'équilibrage
+et le thread de calcul.  Il semble gardé beaucoup trop longtemps.
+
+-- Tue, May 24 14:55:59 2011 +0200

 
 

-Le problème devrait être contourné correctement depuis le commit
-cd6b253 Use MSG_comm_waitall for communicator::flush(true).
+Bon, une partie du problème est rectifiée par le commit
+48de954 Stop locking the mutex on data_receive.
+
+Pour le reste, je pense maintenant que ça ne gêne pas, au moins dans
+le simulateur.  Pour faire bien, il faudrait plus séparer les deux
+threads d'équilibrage et de calcul, et faire en sorte que chacun garde
+un cache des données globales partagées.  Il suffirait alors de
+synchroniser ces caches à chaque itération.
+
+Les données partagées sont essentiellement les données des voisins :
+load, to_send et debt.

 
 ========================================================================
 
 ========================================================================

-Avec SG 3.5, les communications doivent être détruites dès que
-possible avec MSG_comm_destroy().  Si ce n'est pas fait, la simulation
-peut être extrêmement ralentie.
+-- Tue, Apr 19 17:48:39 2011 +0200
+
+Valgrind détecte une fuite de mémoire liée à un appel à backtrace.

 
 

-Le problème devrait être contourné correctement depuis le commit
-404a8d5 Do not call flush automatically in communcator::send...
+Le problème semble être indépendant de SimGrid et peut être reproduit
+avec le code suivant (NB: l'équivalent, compilé avec gcc ne génère pas
+d'erreur).
+,----
+| #include <execinfo.h>
+| #include <iostream>
+| int main()
+| {
+|     void *buffer[64];
+|     int size = -1;
+|     size = backtrace(buffer, sizeof buffer / sizeof buffer[0]);
+|     std::cerr << "backtrace() returned " << size << "\n";
+| }
+`----
+==532== HEAP SUMMARY:
+==532==     in use at exit: 56 bytes in 1 blocks
+==532==     ...
+==532== LEAK SUMMARY:
+==532==    ...
+==532==    still reachable: 56 bytes in 1 blocks

 
 ========================================================================
 
 ========================================================================