Tirer partie d'une architecture SMP avec des (p)thread...
1 réponse
Robert Polson
Bonjour,
Je programme depuis longtemps déjà, en C, des programmes avec des
threads (libraire pthread), qui jusque là avaient toujours su tirer
partie des architectures SMP (bi-processeurs) sur lesquelles ils étaient
utilisés (Linux 2.2.14-5.0smp en RedHat 6.2 sur Bi Pentium).
Avec ou sans l'activation du NPTL (par le passage de l'argument
"nosysinfo" au kernel), j'ai aujourd'hui avec le kernel 2.4.20-8smp sous
RedHat 9, un comportement bien étrange où, sur les mêmes machines, je
n'arrive plus à tirer profits de mes deux processeurs... Plusieur thread
en un seul process et sur un seul processeur restent obstinément et
seulement utilisés.
Voiçi le programme que j'ai à vous soumettre en test (donc sans intérêt
autre que de montrer où est le problème):
sleep(15);
return(0);
}
########################
Vous compilez avec la commande:
"gcc -Wall -o thread_test thread_test.c -lpthread"
Vous executez la commande en tâche de fond (15s d'éxecution maxi), et
regardez pendant ce temps à l'aide de "ps" ou "top" ce qui se passe...
Je n'ai jamais, sur un biprocesseur, 2(proc)*100% de ressources
utilisées... (comme c'était le cas sous l'ancienne distrib avec l'ancien
kernel)...
Quelqu'un peut-il me dire ce que je fais, ou ce que je ne fais pas qui
provoque ce comportement?...
Merci d'avance pour vos réponse...
Bob
NB: le résultat auquel je ne parviens pas, avec cette distribution
Linux, le code MySQL 3.23.56 compilé sur cette même machine y parvient
sans problème... :-|
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Antoine Bellot
Robert Polson a écrit:
Bonjour,
Je programme depuis longtemps déjà, en C, des programmes avec des threads (libraire pthread), qui jusque là avaient toujours su tirer partie des architectures SMP (bi-processeurs) sur lesquelles ils étaient utilisés (Linux 2.2.14-5.0smp en RedHat 6.2 sur Bi Pentium). Avec ou sans l'activation du NPTL (par le passage de l'argument "nosysinfo" au kernel), j'ai aujourd'hui avec le kernel 2.4.20-8smp sous RedHat 9, un comportement bien étrange où, sur les mêmes machines, je n'arrive plus à tirer profits de mes deux processeurs... Plusieur thread en un seul process et sur un seul processeur restent obstinément et seulement utilisés.
Pour Linux, un thread est un processus, et, à ce titre, régi par le scheduler. Or, un Linux récent considère qu'un processus fils doit sauf appel système explicite tourner sur le même ensemble de processeurs que celui autorisé à son père.
Dans le chapitre "Linux Process Scheduler" disponible en ligne de "Linux Kernel Developpement", Robert Love précise :
"This hard affinity is stored as a bitmask in the task's task_struct as cpus_allowed. The bitmask contains one bit per possible processor on the system. By default, all bits are set and, therefore, a process is potentially runnable on any processor. The user, however, via sched_setaffinity(), can provide a different bitmask of any combination of one or more bits. Likewise, the call sched_getaffinity() will return the current cpus_allowed bitmask."
"The kernel enforces hard affinity in a very simple manner. First, when a process is first created, it inherits its parent's affinity mask. Because the parent is running on an allowed processor, the child thus runs on an allowed processor. Second, when the affinity of a processor is changed, the kernel uses the migration threads to push the task onto a legal processor. Finally, the load balancer only pulls tasks to an allowed processor. Therefore, a process only ever runs on a processor whose bit is set in the cpus_allowed field of its process descriptor."
NB: le résultat auquel je ne parviens pas, avec cette distribution Linux, le code MySQL 3.23.56 compilé sur cette même machine y parvient sans problème... :-|
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Robert Polson a écrit:
Bonjour,
Je programme depuis longtemps déjà, en C, des programmes avec des
threads (libraire pthread), qui jusque là avaient toujours su tirer
partie des architectures SMP (bi-processeurs) sur lesquelles ils étaient
utilisés (Linux 2.2.14-5.0smp en RedHat 6.2 sur Bi Pentium).
Avec ou sans l'activation du NPTL (par le passage de l'argument
"nosysinfo" au kernel), j'ai aujourd'hui avec le kernel 2.4.20-8smp sous
RedHat 9, un comportement bien étrange où, sur les mêmes machines, je
n'arrive plus à tirer profits de mes deux processeurs... Plusieur thread
en un seul process et sur un seul processeur restent obstinément et
seulement utilisés.
Pour Linux, un thread est un processus, et, à ce titre, régi par le
scheduler. Or, un Linux récent considère qu'un processus fils doit sauf
appel système explicite tourner sur le même ensemble de processeurs que
celui autorisé à son père.
Dans le chapitre "Linux Process Scheduler" disponible en ligne de "Linux
Kernel Developpement", Robert Love précise :
"This hard affinity is stored as a bitmask in the task's task_struct as
cpus_allowed. The bitmask contains one bit per possible processor on the
system. By default, all bits are set and, therefore, a process is
potentially runnable on any processor. The user, however, via
sched_setaffinity(), can provide a different bitmask of any combination
of one or more bits. Likewise, the call sched_getaffinity() will return
the current cpus_allowed bitmask."
"The kernel enforces hard affinity in a very simple manner. First, when
a process is first created, it inherits its parent's affinity mask.
Because the parent is running on an allowed processor, the child thus
runs on an allowed processor. Second, when the affinity of a processor
is changed, the kernel uses the migration threads to push the task onto
a legal processor. Finally, the load balancer only pulls tasks to an
allowed processor. Therefore, a process only ever runs on a processor
whose bit is set in the cpus_allowed field of its process descriptor."
NB: le résultat auquel je ne parviens pas, avec cette distribution
Linux, le code MySQL 3.23.56 compilé sur cette même machine y parvient
sans problème... :-|
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Je programme depuis longtemps déjà, en C, des programmes avec des threads (libraire pthread), qui jusque là avaient toujours su tirer partie des architectures SMP (bi-processeurs) sur lesquelles ils étaient utilisés (Linux 2.2.14-5.0smp en RedHat 6.2 sur Bi Pentium). Avec ou sans l'activation du NPTL (par le passage de l'argument "nosysinfo" au kernel), j'ai aujourd'hui avec le kernel 2.4.20-8smp sous RedHat 9, un comportement bien étrange où, sur les mêmes machines, je n'arrive plus à tirer profits de mes deux processeurs... Plusieur thread en un seul process et sur un seul processeur restent obstinément et seulement utilisés.
Pour Linux, un thread est un processus, et, à ce titre, régi par le scheduler. Or, un Linux récent considère qu'un processus fils doit sauf appel système explicite tourner sur le même ensemble de processeurs que celui autorisé à son père.
Dans le chapitre "Linux Process Scheduler" disponible en ligne de "Linux Kernel Developpement", Robert Love précise :
"This hard affinity is stored as a bitmask in the task's task_struct as cpus_allowed. The bitmask contains one bit per possible processor on the system. By default, all bits are set and, therefore, a process is potentially runnable on any processor. The user, however, via sched_setaffinity(), can provide a different bitmask of any combination of one or more bits. Likewise, the call sched_getaffinity() will return the current cpus_allowed bitmask."
"The kernel enforces hard affinity in a very simple manner. First, when a process is first created, it inherits its parent's affinity mask. Because the parent is running on an allowed processor, the child thus runs on an allowed processor. Second, when the affinity of a processor is changed, the kernel uses the migration threads to push the task onto a legal processor. Finally, the load balancer only pulls tasks to an allowed processor. Therefore, a process only ever runs on a processor whose bit is set in the cpus_allowed field of its process descriptor."
NB: le résultat auquel je ne parviens pas, avec cette distribution Linux, le code MySQL 3.23.56 compilé sur cette même machine y parvient sans problème... :-|
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
