Forum général.général comment changer dynamiquement la priorité de l'application active ?

Posté par .
Tags : aucun
1
18
mar.
2010
Bonjour,

Linux gère les priorités des applications de manière statique, et il est possible de modifier la priorité d'une application manuellement grace aux commandes "nice" et "renice".

Est-ce qu'il existe une application pour mettre automatiquement une priorité importante à la fenêtre active, et réduire la prorité lorsque la fenêtre devient inactive ?

Sans ce type de manipulation, l'interface utilisateur peut ramer parfois...

Merci d'avance.
  • # Re:

    Posté par . Évalué à 2.

    À ma connaissance ça n'existe pas et ça n'existera peut-être jamais sous Linux.
    L'un des problèmes est que pour remonter la priorité il faut être super-utilisateur.

    Puis maintenant avec les quadri-coeur qui se multiplient c'est quasiment sans intérêt.
    • [^] # Re: Re:

      Posté par . Évalué à 1.

      Pas la peine d'être root pour "remonter" la priorité, si on est propriétaire du processus. (plus la valeur est haute, moins le processus est prioritaire). C'est pour aller en dessous de 0 qu'on doit être root.

      On peut très bien imaginer un système qui met le nice à 10 pour tous les processus de l'utilisateur, et à 0 pour celui en premier plan. Ou alors 0 pour tous, et quand on iconifie une appli => renice à +10 par ex.

      Mais c'est un pis-aller, il faudrait plutot voir si la machine n'est pas sous-dimensionnée, ou quel processus prend toutes les resources...
      • [^] # Re: Re:

        Posté par . Évalué à 2.

        Non.

        $ cat &
        [2] 32759
        $ renice 10 32759
        32759: priorité précédente 0, nouvelle priorité 10
        $ renice 5 32759
        renice: 32759: setpriority: Permission non accordée
        • [^] # Re: Re:

          Posté par . Évalué à 2.

          sur la mienne ca marche :
          neox@neox-c2d:~$ renice 5 29786
          29786: priorité précédente 10, nouvelle priorité 5
          neox@neox-c2d:~$ renice 1 29786
          29786: priorité précédente 5, nouvelle priorité 1
          neox@neox-c2d:~$ renice 10 29786
          29786: priorité précédente 1, nouvelle priorité 10
          • [^] # Re: Re:

            Posté par . Évalué à 2.

            Bizarre, j'ai jamais vu ça sous Linux.
            De la man page :
            Les utilisateurs, autres que le superutilisateur, peuvent seulement modifier la priorité des processus dont ils sont propriétaires, et peuvent seulement incrémenter monotoniquement leur valeur de courtoisie dans l’intervalle 0 à PRIO_MAX (20). (Ceci empêche d’écraser les autorisations administratives.)
            • [^] # Re: Re:

              Posté par . Évalué à 2.

              Et aussi :
              Les utilisateurs, qui ne sont pas superutilisateur, ne peuvent pas augmenter les priorités d’ordonnancement de leurs propres processus, même s’ils avaient eux-même diminué les priorités préalablement.
              • [^] # Re: Re:

                Posté par . Évalué à 2.

                Ma distrib ici :
                Ubuntu Linux 64bits 9.10

                Version de "renice" :
                - util-linux-ng 2.16
                • [^] # Re: Re:

                  Posté par . Évalué à 2.

                  Ouais, Ubuntu, le userfriendly à tout prix...
                  C'est soit un patch noyau, soit renice est suid.
                  Ici util-linux-ng-2.17.1
                  • [^] # Re: Re:

                    Posté par . Évalué à 2.

                    patch noyau ?
                    neox@neox-c2d:~$ ls -l `which renice`
                    -rwxr-xr-x 1 root root 10432 2009-10-23 06:28 /usr/bin/renice
                    • [^] # Re: Re:

                      Posté par . Évalué à 2.

                      C'est un patch noyau alors. J'ai un 2.6.33.
  • # Priorité pour les threads

    Posté par (page perso) . Évalué à 1.

    Je n'ai jamais testé le changement de priorité pour les processus, mais c'est possible pour les threads :


    struct sched_param thread_param;
    thread_param.sched_priority = prio;
    if((err = pthread_setschedparam (pthread_self(), SCHED_FIFO, &thread_param))) {
    fprintf(stderr, "cannot change my priority (err %d)\n", err);
    }


    Il faut juste que l'utilisateur soit dans le groupe realtime.
    • [^] # Re: Priorité pour les threads

      Posté par . Évalué à 2.

      L'utilisation des classes d'ordonnancement temps réel doit rester exceptionnelle. Comprendre qu'en général c'est une connerie.
    • [^] # Re: Priorité pour les threads

      Posté par . Évalué à 2.

      Comme ça, si l'application boucle (ce qui arrive souvent avec les applications graphiques :-), tu es bon pour redémarrer la machine...
      • [^] # Re: Priorité pour les threads

        Posté par (page perso) . Évalué à 1.

        En fait, ça dépend de ce que tu veux faire. Le changement de priorité peut avoir du bon si tu ne veux pas qu'un thread ait la main trop souvent (oui, on peut aussi *baisser* la priorité d'un thread !)

        Ensuite, pour éviter qu'un thread ne garde le processeur pour lui tout seul, il existe des mécanismes. Et heureusement d'ailleurs, sinon je vois mal comment les gens qui font du real-time pourraient développer (personnellement, tous les gens que je connais font une boulette de temps en temps)
        • [^] # Re: Priorité pour les threads

          Posté par . Évalué à 2.

          En fait, ça dépend de ce que tu veux faire. Le changement de priorité peut avoir du bon si tu ne veux pas qu'un thread ait la main trop souvent (oui, on peut aussi *baisser* la priorité d'un thread !)
          Tu peux mettre la priorité que tu veux, à partir du moment où tu lui donnes une "policy" real-time, il aura toujours une priorité plus haute qu'un process normal (SCHED_OTHER).

          Ensuite, pour éviter qu'un thread ne garde le processeur pour lui tout seul, il existe des mécanismes.
          Certes, mais tout le monde n'a pas un shell lancé avec une priorité real-time sur sa machine...

          De façon plus générale, du real-time pour une application graphique, c'est quand même bizarre. Son impression de latence de l'interface graphique est peut-être due justement au fait qu'il n'y a qu'un seul thread qui s'occupe de l'affichage et des calculs, et donc lorsqu'il mouline, l'interface n'est pas réactive.
          • [^] # Re: Priorité pour les threads

            Posté par . Évalué à 2.

            Certes, mais tout le monde n'a pas un shell lancé avec une priorité real-time sur sa machine...

            Et ça ne suffit pas, faut aussi que le shell soit sur une console (pas via ssh ou x11, etc).

Suivre le flux des commentaires

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