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

Posté par earlone le 18 mars 2010 à 02:25.

Étiquettes : aucune

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 IsNotGood le 18 mars 2010 à 03:13. É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 jigso le 18 mars 2010 à 19:16. É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 IsNotGood le 18 mars 2010 à 20:34. É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 NeoX le 18 mars 2010 à 21:26. É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 IsNotGood le 20 mars 2010 à 02:05. É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 IsNotGood le 20 mars 2010 à 02:08. É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 NeoX le 20 mars 2010 à 13:59. Évalué à 2.
        
        Ma distrib ici :
        Ubuntu Linux 64bits 9.10
        
        Version de "renice" :
        - util-linux-ng 2.16
        
        [^] # Re: Re:
        
        Posté par IsNotGood le 20 mars 2010 à 18:32. É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 NeoX le 20 mars 2010 à 19:12. É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 IsNotGood le 21 mars 2010 à 01:36. Évalué à 2.
        
        C'est un patch noyau alors. J'ai un 2.6.33.
# Priorité pour les threads

Posté par François Trahay (site web personnel) le 18 mars 2010 à 10:51. É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 IsNotGood le 18 mars 2010 à 20:38. É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 neologix le 18 mars 2010 à 20:41. É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 François Trahay (site web personnel) le 19 mars 2010 à 00:49. É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 neologix le 19 mars 2010 à 15:25. É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 IsNotGood le 20 mars 2010 à 02:12. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.