temps CPU > 100%

Le
Vincent Lefevre
Est-ce que c'est normal d'avoir un temps CPU > 100%?

courge:> /usr/bin/time ./dblmult 5 -
[]
0.01user 0.00system 0:00.00elapsed 333%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+213minor)pagefaults 0swaps

Même problème avec le builtin de time de zsh.

Si c'est un bug, d'où vient-il? Du noyau? De l'utilitaire time qui ne
fait pas telle ou telle correction nécessaire?

--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Basile STARYNKEVITCH
Le #9670121
Vincent Lefevre wrote:
Est-ce que c'est normal d'avoir un temps CPU > 100%?

courge:...> /usr/bin/time ./dblmult 5 -
[...]
0.01user 0.00system 0:00.00elapsed 333%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+213minor)pagefaults 0swaps

Même problème avec le builtin de time de zsh.

Si c'est un bug, d'où vient-il? Du noyau? De l'utilitaire time qui ne
fait pas telle ou telle correction nécessaire?




A mon avis ce n'est pas un bogue. La commande time doit s'appuyer sur
l'appel système times ou getrusage qui renvoie le temps CPU, et
lorsqu'on a plus d'un processeur (cas des multicores actuels) qui
travaille sur le processus mesuré (ainsi que ses fils et ses threads!)
le temps cpu est supérieur au temps réel. Par exemple, si les 2
processeurs tournent à fond pendant une seconde, le temps cpu sera de 2
secondes.

Par contre, le temps mesuré n'est vraiement significatif que s'il a été
suffisamment echantillonné. Il faudrait donc lancer une commande qui
prend un certain temps (typiquement plus d'une seconde de CPU) pour que
la mesure soit significative.


--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Vincent Lefevre
Le #9670101
On 2008-05-19 15:18:59 +0200, Basile STARYNKEVITCH wrote:
A mon avis ce n'est pas un bogue. La commande time doit s'appuyer sur
l'appel système times ou getrusage qui renvoie le temps CPU, et
lorsqu'on a plus d'un processeur (cas des multicores actuels) qui
travaille sur le processus mesuré (ainsi que ses fils et ses threads!)



La machine a plus d'un processeur, mais je précise que le processus
ne fait pas de fork, et il ne crée pas de threads non plus. C'est un
programme C standard (ISO C99) tout bête.

le temps cpu est supérieur au temps réel. Par exemple, si les 2
processeurs tournent à fond pendant une seconde, le temps cpu sera de 2
secondes.

Par contre, le temps mesuré n'est vraiement significatif que s'il a été
suffisamment echantillonné. Il faudrait donc lancer une commande qui
prend un certain temps (typiquement plus d'une seconde de CPU) pour que
la mesure soit significative.



Oui, c'est la source du problème, et d'ailleurs dès que la commande
prend plus de temps (valeur donnée en argument plus élevée), le temps
CPU est bien toujours <= 100%.

Note: je sais bien que c'est imprécis, mais la commande time ne
devrait-elle pas fournir un comportement *cohérent* avec la réalité?

Je vois deux raisons à vouloir un résultat cohérent:
_ Pour les humains, qui peuvent se poser des questions lorsqu'une
valeur > 100% est obtenue.
_ Pour les programmes, lorsque la sortie de time est traitée par
un autre programme: celui-ci risque de se comporter de manière
erratique, voire quelque chose de plus sérieux comme un buffer
overflow.

--
Vincent Lefèvre 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Basile STARYNKEVITCH
Le #9670091
Vincent Lefevre wrote:
On 2008-05-19 15:18:59 +0200, Basile STARYNKEVITCH wrote:
Par contre, le temps mesuré n'est vraiement significatif que s'il a été
suffisamment echantillonné. Il faudrait donc lancer une commande qui
prend un certain temps (typiquement plus d'une seconde de CPU) pour que
la mesure soit significative.



Oui, c'est la source du problème, et d'ailleurs dès que la commande
prend plus de temps (valeur donnée en argument plus élevée), le temps
CPU est bien toujours <= 100%.

Note: je sais bien que c'est imprécis, mais la commande time ne
devrait-elle pas fournir un comportement *cohérent* avec la réalité?



Ce n'est pas dans la philosophie d'Unix, au moins à son origine.

A l'époque, on cherchait plutot à implémenter simplement. Une
implémentation simple serait par exemple

le processeur (ou un autre matériel) émet une interruption temporelle à
chaque milliseconde la mesure du temps CPU, et une autre sorte
d'interruption temporelle à chaque centiseconde (qui ne tombe pas en
même temps que la précédente) pour la mesure du temps d'horloge (temps
"réel").

L'ordonnanceur du noyau:

quand il recoit une interruption temporelle pour la CPU (chaque
milliseconde) incrémente un compteur dans le description de tache
courante et réordonne les processus (donc en active un autre).

quand il reçoit une interruption temporelle pour le temps d'horloge
(chaque centiseconde) incémente un compteur global (servant à la mesure
du temps) et réordonne les processus.

Il me semble quand dans un tel cas il existe un scénario (un peu
pathologique) où ton processus a deux ou trois top de temps CPU mais un
seul (voire aucun) top de temps horloge.

Je suis donc suffisamment vieux pour ne pas être choqué par le temps CPU
> 100%.

Je n'exige pas du noyau qu'il soit cohérent, mais qu'il marche à peu
près. Et quand tu songes qu'il doit faire quelque chose quand on dérègle
l'heure (et là ça devient compliqué), ou quand le processeur se
ralentit, ça me suffit. J'ai autrefois lu un papier décrivant un
algorithme de synchronisation d'horloge, je n'ai rien compris (c'est
trop matheux pour moi) et j'ai eu la migraine. Dans le détail, c'est un
métier!

Tu peux toujours réécrire time (utilisant getrusage ou times) qui te
retourne toujours une charge CPU < 100% (par exemple quand les temps
mesurés sont moins que la demiseconde, retourner une charge aléatoire
entre 0 et 100%).

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Vincent Lefevre
Le #9669981
On 2008-05-19 17:16:46 +0200, Basile STARYNKEVITCH wrote:
Je n'exige pas du noyau qu'il soit cohérent, mais qu'il marche à peu
près.



En fait, ce n'est probablement pas corrigeable dans le noyau, auquel
cas c'est à la commande time (c'est d'ailleurs cette commande qui va
faire le lien entre les deux types de temps) de s'occuper du problème,
surtout que la documentation est plutôt floue.

--
Vincent Lefèvre 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Publicité
Poster une réponse
Anonyme