Commit 9c43d097 authored by aumgn's avatar aumgn
Browse files

[cleanup] Remove unused journal

parent 6288bfa5
#+TITLE: Journal
#+AUTHOR: Christopher Ferreira
* <2017-04-06 jeu.>
** Volrend bottleneck
Après un certain temps a essayer de trouver d'ou venez le problème de perf avec volrend, j'ai réussi a localiser (à l'aide de l'outils 'perf top') un bottleneck.
Le code de volrend utilise des barrières pour synchroniser l'avancement de ces threads.
Le coupable est une de ces barrières qui est implementée en attente active :
Voir fichier 'adaptive.C' lignes 94-97 & 135-138
#+NAME: volrend-attente-active
#+BEGIN_SRC c
LOCK(Global->CountLock);
Global->Counter--;
UNLOCK(Global->CountLock);
while (Global->Counter);
#+END_SRC
** Autogroup
La dernière fois, j'ai découvert que la différence de perf de l'application volrend était en grande partie du à la fonctionnalité autogroup du kernel.
:RESULTS:
[[./img/volrend-autogroup.png]]
:END:
On peut remarquer qu'il y a toujours une différence entre une execution pinné et une execution non pinné. Notamment avec 8 coeurs : 14.63 -> 22.39 soit +35%. D'après Hugo, l'importance de l'autogroup dans la différence de perf est moins marqué sur une multicore intel.
** Influence du placement initial
Afin d'essayer d'obtenir une meilleur idée de la nature du problème de perf.
J'ai fait une experience avec une version modifiée de volrend qui dispatch les threads (i.e: 1 thread<->1 core) à leur création sur l'ensemble des cores disponibles et les relachent après.
Ceci est fait avec deux appels à 'pthread_setaffinity_np' pour chaque thread, le premier ible, le second pour permettre a nouveau le placement du thread sur n'importe qu'elle thread.
L'idée étant que le premier appel va forcer les thread a être migrés sur les cores pour avoir initialement la meme repartition que dans le cas du pinning.
Le second appel va lui de repasser en mode non-pinné. L'execution est ainsi hybride entre le pinning et le non-pinning.
On peut ainsi essayer de determiner si le problème provient du fait que le load balancing ne fait pas son travail ou si il fait des choix de mauvais placement/migrations (comme la configuration initial est aussi idéale que celle du pinning).
#+NAME: initial-pinning-patch
#+BEGIN_SRC diff
diff --git a/src/main.C b/src/main.C
index e41b9cb..82b95c7 100644
--- a/src/main.C
+++ b/src/main.C
@@ -26,12 +26,15 @@
*************************************************************************/
+#define _GNU_SOURCE
+#include <sched.h>
#include "incl.h"
#include <string.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <limits.h>
#include "tiffio.h"
+#include <pthread.h>
#define SH_MEM_AMT 60000000
@@ -70,6 +73,7 @@ void mclock(long stoptime, long starttime, long *exectime)
*exectime = (stoptime - starttime)/1000;
}
+int dispatch = 0;
int main(int argc, char *argv[])
{
@@ -91,8 +95,10 @@ int main(int argc, char *argv[])
if (argc == 5) {
if (strncmp(argv[4],"-a",strlen("-a")) == 0)
adaptive = YES;
+ else if (strncmp(argv[4],"-d",strlen("-d")) == 0)
+ dispatch = 1;
else {
- printf("usage: VOLREND num_processes input_file ROTATE_STEPS [-a] \n");
+ printf("usage: VOLREND num_processes input_file ROTATE_STEPS [-a|-d] \n");
exit(-1);
}
}
@@ -266,6 +272,19 @@ void Render_Loop()
/* POSSIBLE ENHANCEMENT: Here's where one might bind the process to a
processor, if one wanted to.
*/
+ if (dispatch) {
+ cpu_set_t old_cpuset;
+ cpu_set_t tmp_cpuset;
+ CPU_ZERO(&tmp_cpuset);
+ CPU_SET(my_node, &tmp_cpuset);
+
+ pthread_getaffinity_np(pthread_self(), sizeof(cpu_set_t), &old_cpuset);
+ pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &tmp_cpuset);
+ pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &old_cpuset);
+
+ int cpu = sched_getcpu();
+ printf("Set up node %d on cpu %d\n", my_node, cpu);
+ }
inv_num_nodes = 1.0/(float)num_nodes;
image_partition = ROUNDUP(image_length*inv_num_nodes);
#+END_SRC
Après éxecution, les performances sont les mêmes que pour une execution non-pinné. De mauvais choix de migration seraient donc le problème.
** TODO
+ Faire des tests en augmentant le paramètre kernel.sched_migration_cost_ns. L'augmenter suffisament devrait normalement correspondre a un pinning par noeud.
+ Essayer de créer une application plus minimal reproduisant le comportement de volrend (barrière attente active + différence de perf pinning/sans-pinning) pour pouvoir faire des tests plus simplement dans le futur.
* <2017-04-20 jeu.>
** Un peu de biblio
** Essai avec KernelShark
+ Utilise ftrace
+ Interface graphique très lente
** Impossible de reproduire la difference de perf de volrend
+ Verification des paramètres sched_migration_cost & sched_autogroup_enabled
=> Nope !
** mvolrend
+ Plus le nombre d'iterations est grand plus la différence de perf se réduit !
=> Différence de perf dûe au placement initial des threads ?
+ Modification de mvolrend pour pouvoir comparer trois strategie de placement :
- default: celle du kernel
- spread: initialise sur des cores différents mais laisse le kernel faire des migrations
- pinned: pinning avec les threads repartis sur les differents cores.
* <2017-04-28 ven.>
** Etude du code source du scheduler (fichier migrations/migrations.org)
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment