Forum Linux.noyau Statistiques précises du temps CPU utilisé

Posté par  .
Étiquettes : aucune
0
21
mar.
2005
Salut

Je recherche depuis un moment un moyen de connaître le temps CPU système et utilisateur utilisé par un processus, avec les contraintes suivantes:

- à partir d'un programme en C

- processus spécifié par son PID (quelconque, ou éventuellement seulement pour un des fils du processus en cours)

- avec une précision de 1ms ou mieux

- sur un noyau standard 2.6

J'ai déjà regardé les solutions suivantes:

- getrusage: ne marche pas pour avoir le temps CPU d'un seul fils apparemment

- /proc/pid/stat: précision insuffisante (10ms semblerait-il)

Quelqu'un aurait une autre idée?

Merci!

  • # libgtop

    Posté par  . Évalué à 1.

    #include <glibtop/cpu.h>

    glibtop_cpu buf;

    glibtop_init ();

    glibtop_get_cpu (&buf);
    buf.idle; /* ca doit etre la dedans */

    glibtop_close ();

    • [^] # Re: libgtop

      Posté par  . Évalué à 2.

      Ben ça le fait pas trop...


      All CPU units are measured in "jiffies" which are normally 1/100th
      of a second (in which case `frequency' equals 100), but can also be in
      any other unit. To get seconds, divide them by `frequency'.


      D'où une précision de 10ms là où j'en voudrais 1 :(

      Ou j'ai loupé quelque chose?

      • [^] # Re: libgtop

        Posté par  (site web personnel) . Évalué à 0.

        je ne sais pas d ou va vient, mais renseigne toi sur la date de cette source ...

        1/100th of s, c est justement le scheduling time d un 2.4 ordinaire, et comme sur 2.6 on est passe normalement a 1000Hz, la precision devrait etre descendue a 1ms ...

        compare donc la date de cette doc, et cherche si la fonction dont le mec parle a ete patchee pour 2.6.

        Je dis ca ... je dis rien.

      • [^] # Re: libgtop

        Posté par  . Évalué à 1.

        ben ça viens du noyau, les stats je les invente pas !

  • # Re:

    Posté par  . Évalué à 3.

    Je ne suis pas sûr, mais il me semble qu'avec un noyau standard, le scheduler ne peut être plus précis que 10 ms (environ). Donc si ce que je dis est vrai, tu ne pourras pas être plus précis.

    Cette "imprécision" se voit par exemple quand ton programme doit recevoir un signal. Le signal est reçu (dans le pire des cas) 10ms après.

    Après, il me semble que ces 10 ms peuvent être rabaissés moyennant le réglage de je ne sais plus quel paramètre dans le noyau (une option qui est en rapport avec time scheduler). Mais celà ne fait déjà plus partie de ton cahier des charges ;-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.