Re: SMP: Forcer une application à tourner sur un processeur

Top Page

Reply to this message
Author: Francois-Xavier Kowalski
Date:  
To: Mailing List GUILDE
Subject: Re: SMP: Forcer une application à tourner sur un processeur
Le Fri 20/12/2002 à 19:56, Patrice Karatchentzeff a écrit :
> olivier_allard-jacquin@??? écrivait :
>  >     Bonjour,

> >
> > j'ai une petite question: Sur une machine multi-processeurs,
> > est-il possible de forcer une application mono-thread à tourner
> > sur un processeur en particulier ?
>
> A priori, non.


C'est exact -- tant que l'on reste en user-space -- sur un noyau 2.4 par
defaut, donc sur un noyau Debian.

En revanche, si on accepte de developper un bout de module kernel (par
exemple un petit driver caractere qui n'implemente que le open(2) & le
close(2)...) il existe un champ (bitmask) "cpu_allowed" dans la
structure "task". Il suffit de la modifier pour n'y laisser que le CPU
courrant (smp_processor_id). Et le tour est joue... :-)

Evidement, pour etre un minimum propre, il faut restaurer le precedent
bitmask quand on appelle le close(2) sur ce driver.

A partir de 2.5 (ou de RedHat 7.3...) le patch "cpu-affinity" est
present. Il ajoute 2 appels systeme permettant de faire ce travail.

- sched_setaffinity
- sched_getaffinity

Aucun des 2 n'est evidement documente pour le moment... :-(

Mais tu peux regarder le fichier noyau source
/usr/src/linux/kernel/sched.c:

/**
 * sys_sched_setaffinity - set the cpu affinity of a process
 * @pid: pid of the process
 * @len: length in bytes of the bitmask pointed to by user_mask_ptr
 * @user_mask_ptr: user-space pointer to the new cpu mask
 */
asmlinkage int sys_sched_setaffinity(pid_t pid, unsigned int len,
                      unsigned long *user_mask_ptr)




> > Je m'explique: J'ai une application qui fait excusivement du
> > calcul, et je pense que la plupart des opérations se font dans le
> > cache du CPU. Hors sur mon Linux (kernel 2.4.20 SMP) j'ai
> > remarqué que le process de l'application passait sans cesse d'un
> > processeur à l'autre. Pour le process, le changement de CPU
> > implique une synchronisation des mémoires caches des CPU, et je
> > pense que je perds quelques cycles d'horloge dans ceci.
>
> J'avais le même soucis sous Solaris. Or, après avoir cherché un peu,
> la réponse que j'avais eu est que les cycles perdues sont négligeables
> par rapport aux cycles user du processus.


Question d'appreciation... :-)

Ur un system MP (symetrique ou pas), on trouve les 2 entrees suivantes
dans la sortie de "top:

2 root      0K   0     0    0     0 SW    0.0  0.0   0:00 migration_CPU0
3 root      0K   0     0    0     0 SW    0.0  0.0   0:00 migration_CPU1


Si la consommation de ces 2 taches devient non negligeable, il est temps
de prendre le taureau par les cornes.

Les applictions dont le temps de reponse est crtique (traitement de la
voix) mais qui be veulent malgre tout pas monopoliser un processeur
(avec une tres haute priorite) ont tout a gagner a se "louer sur un
processeur.

A+
--
Francois-Xavier 'FiX' KOWALSKI