X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/loba.git/blobdiff_plain/cd6b2539af2f8564684f287983ffb05bb0f7b285..526e1f382ddc9f0010c41a526f3029af769162c9:/BUGS?ds=inline diff --git a/BUGS b/BUGS index e69de29..632bdde 100644 --- a/BUGS +++ b/BUGS @@ -0,0 +1,96 @@ +======================================================================== +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). + +Corrigé en partie. Il reste quelques "fixme: get locked?" à régler +(ou pas). + +======================================================================== +##### RESOLVED BUGS COME AFTER THIS #################################### +======================================================================== +Il faut réviser l'utilisation du mutex entre le thread d'équilibrage +et le thread de calcul. Il semble gardé beaucoup trop longtemps. + +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. + +======================================================================== +Comment expliquer ces différences entre SG 3.5 et SG svn ? + +$ ./loba platform.xml -Tline -abest -L500 -t1800 -c1e8,0 -C1e7,0 -M0 2>&1 --log=comm.thres:debug -s100 -b | grep LOAD +[Bourassa 1031.097913] [comm/DEBUG] send LOAD: 366.211 to Fafard_data +[Bourassa 1306.997159] [comm/DEBUG] send LOAD: 20.0806 to Fafard_data +[Bourassa 1541.486345] [comm/DEBUG] send LOAD: 4.74548 to Fafard_data +[Bourassa 1766.189415] [comm/DEBUG] send LOAD: 3.09753 to Fafard_data +[Fafard 2579.229566] [comm/DEBUG] received LOAD: 366.211 from Bourassa +[Fafard 2605.989948] [comm/DEBUG] received LOAD: 20.0806 from Bourassa +[Fafard 2612.318155] [comm/DEBUG] received LOAD: 4.74548 from Bourassa +[Fafard 2616.450666] [comm/DEBUG] received LOAD: 3.09753 from Bourassa + +$ ./loba-dev platform_dev.xml -Tline -abest -L500 -t1800 -c1e8,0 -C1e7,0 -M0 2>&1 --log=comm.thres:debug -s100 -b | grep LOAD +[Bourassa 1031.097913] [comm/DEBUG] send LOAD: 366.211 to Fafard_data +[Bourassa 1306.997159] [comm/DEBUG] send LOAD: 20.0806 to Fafard_data +[Fafard 1519.035900] [comm/DEBUG] received LOAD: 366.211 from Bourassa +[Fafard 1519.035900] [comm/DEBUG] send LOAD: 282.074 to Ginette_data +[Bourassa 1541.486345] [comm/DEBUG] send LOAD: 4.74548 to Fafard_data +[Fafard 1629.312931] [comm/DEBUG] received LOAD: 20.0806 from Bourassa +[Fafard 1629.312931] [comm/DEBUG] received LOAD: 4.74548 from Bourassa +[Fafard 1629.312931] [comm/DEBUG] send LOAD: 6.19507 to Ginette_data +[Bourassa 1766.189415] [comm/DEBUG] send LOAD: 3.09753 to Fafard_data +[Fafard 1898.705676] [comm/DEBUG] received LOAD: 3.09753 from Bourassa +[Ginette 1932.076243] [comm/DEBUG] received LOAD: 282.074 from Fafard +[Ginette 1940.343540] [comm/DEBUG] received LOAD: 6.19507 from Fafard + +Probablement par un bug dans SG 3.5. + +======================================================================== +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. + +Le problème devrait être contourné correctement depuis le commit +cd6b253 Use MSG_comm_waitall for communicator::flush(true). + +======================================================================== +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. + +Le problème devrait être contourné correctement depuis le commit +404a8d5 Do not call flush automatically in communcator::send... + +======================================================================== +Valgrind détecte une fuite de mémoire liée à un appel à backtrace. + +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 + +========================================================================