après des années d'utilisation, je me rends compte que si l'occasion
de donner une "gentillesse" positive aux processus est fréquente, voire
banale, je n'ai jamais réellement eu à rendre des processus méchants
(mon utilisation correspond à celle d'un ordinateur personnel) ;
les rares fois où je l'ai fait, j'admets sans réserve que c'était forcé
(plus pour le plaisir d'essayer), sale (obligé de passer en root), voire
même que s'il avait réellement fallu utiliser 'nice' cela aurait dû être
dans l'autre sens (exemple : gros calculs).
Du coup j'aimerais avoir des bons exemple de cas où le coefficient négatif
apporte réellement quelque chose. Pourriez-vous me donner ce genre
d'exemples ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Bourguignon
Thomas Baruchel writes:
Par simple curiosité :
après des années d'utilisation, je me rends compte que si l'occasion de donner une "gentillesse" positive aux processus est fréquente, voire banale, je n'ai jamais réellement eu à rendre des processus méchants (mon utilisation correspond à celle d'un ordinateur personnel) ; les rares fois où je l'ai fait, j'admets sans réserve que c'était forcé (plus pour le plaisir d'essayer), sale (obligé de passer en root), voire même que s'il avait réellement fallu utiliser 'nice' cela aurait dû être dans l'autre sens (exemple : gros calculs).
Du coup j'aimerais avoir des bons exemple de cas où le coefficient négatif apporte réellement quelque chose. Pourriez-vous me donner ce genre d'exemples ?
Sur une machine chargée, je donne une plus grande priorité à mplayer pour éviter les à-coups.
Mais je ne suis pas sur que ça soit vraiment efficace...
-- __Pascal Bourguignon__ http://www.informatimago.com/ "Specifications are for the weak and timid!"
Thomas Baruchel <archaiesteron@laposte.net> writes:
Par simple curiosité :
après des années d'utilisation, je me rends compte que si l'occasion
de donner une "gentillesse" positive aux processus est fréquente, voire
banale, je n'ai jamais réellement eu à rendre des processus méchants
(mon utilisation correspond à celle d'un ordinateur personnel) ;
les rares fois où je l'ai fait, j'admets sans réserve que c'était forcé
(plus pour le plaisir d'essayer), sale (obligé de passer en root), voire
même que s'il avait réellement fallu utiliser 'nice' cela aurait dû être
dans l'autre sens (exemple : gros calculs).
Du coup j'aimerais avoir des bons exemple de cas où le coefficient négatif
apporte réellement quelque chose. Pourriez-vous me donner ce genre
d'exemples ?
Sur une machine chargée, je donne une plus grande priorité à mplayer
pour éviter les à-coups.
Mais je ne suis pas sur que ça soit vraiment efficace...
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Specifications are for the weak and timid!"
après des années d'utilisation, je me rends compte que si l'occasion de donner une "gentillesse" positive aux processus est fréquente, voire banale, je n'ai jamais réellement eu à rendre des processus méchants (mon utilisation correspond à celle d'un ordinateur personnel) ; les rares fois où je l'ai fait, j'admets sans réserve que c'était forcé (plus pour le plaisir d'essayer), sale (obligé de passer en root), voire même que s'il avait réellement fallu utiliser 'nice' cela aurait dû être dans l'autre sens (exemple : gros calculs).
Du coup j'aimerais avoir des bons exemple de cas où le coefficient négatif apporte réellement quelque chose. Pourriez-vous me donner ce genre d'exemples ?
Sur une machine chargée, je donne une plus grande priorité à mplayer pour éviter les à-coups.
Mais je ne suis pas sur que ça soit vraiment efficace...
-- __Pascal Bourguignon__ http://www.informatimago.com/ "Specifications are for the weak and timid!"
david
Patrick Lamaizière wrote:
Pascal Bourguignon écrivait :
Sur une machine chargée, je donne une plus grande priorité à mplayer pour éviter les à-coups.
Mais je ne suis pas sur que ça soit vraiment efficace...
Sur le démon son de KDE artsd ça améliore un peu.
Pour artsd, sur ma machine (linux-x86) bonatoufer, le nice ne suffit pas. Alors je fais un truc pas très catholique au lancement du système :
nohup sh -c "while true; do chrt -f 99 su nobody -c "/usr/bin/artsd -a alsa -d -u -n -p 1025"; killall xmms mplayer; sleep 5; done" >& /tmp/aRts.log &
et je positionne ARTS_SERVER=localhost:1025 dans le profile global.
Cependant, il me semble que chrt est spécifique linux.
Le "while true" sert à relancer artsd des fois qu'il s'écroule. Ça arrive et je ne sais pas pourquoi.
Il faut faire gaffe avec chrt, si jamais il prenait au processus (artsd) l'envie de prendre tout le cpu, la boite serait bonne pour le reset.
A ce sujet, j'ai une question, en rapport avec le contraire du sujet de ce thread. J'aimerais avoir des processus (très gentils) de calcul en tâche de fond, qui eux auraient bien envie de prendre en permanence 100% du cpu (je sais que ce n'est pas très écologique...) mais qui ne doivent absolument pas gêner les autres.
La solution immédiate est "nice -n +19 commande...". Mais elle n'est que moyennement satisfaisante. On peut avec chrt mettre en priorité absolue un processus devant les autres (comme chrt -f nn). Y a-t-il un moyen (en particulier sous linux ou solaris) de rendre le gentil processus réellement sous-prioritaire ? J'entend par là : si rien n'est actif dans la file d'attente, alors on donne la main à ce processus, mais si un ou plusieurs des autres processus normaux se réveille alors le gentil processus n'a plus la main jusqu'à ce que les autres se rendorment. (sous linux, chrt -f -1 n'est pas possible sans toucher au noyo, ce que je n'ai pas encore essayé).
david
Patrick Lamaizière <adresse@est.invalid> wrote:
Pascal Bourguignon écrivait :
Sur une machine chargée, je donne une plus grande priorité à mplayer
pour éviter les à-coups.
Mais je ne suis pas sur que ça soit vraiment efficace...
Sur le démon son de KDE artsd ça améliore un peu.
Pour artsd, sur ma machine (linux-x86) bonatoufer, le nice ne suffit
pas. Alors je fais un truc pas très catholique au lancement du système :
nohup sh -c "while true; do chrt -f 99 su nobody -c "/usr/bin/artsd -a alsa
-d -u -n -p 1025"; killall xmms mplayer; sleep 5; done" >& /tmp/aRts.log &
et je positionne
ARTS_SERVER=localhost:1025
dans le profile global.
Cependant, il me semble que chrt est spécifique linux.
Le "while true" sert à relancer artsd des fois qu'il s'écroule. Ça arrive et
je ne sais pas pourquoi.
Il faut faire gaffe avec chrt, si jamais il prenait au processus (artsd)
l'envie de prendre tout le cpu, la boite serait bonne pour le reset.
A ce sujet, j'ai une question, en rapport avec le contraire du sujet de ce
thread. J'aimerais avoir des processus (très gentils) de calcul en tâche de
fond, qui eux auraient bien envie de prendre en permanence 100% du cpu (je
sais que ce n'est pas très écologique...) mais qui ne doivent absolument pas
gêner les autres.
La solution immédiate est "nice -n +19 commande...". Mais elle n'est que
moyennement satisfaisante. On peut avec chrt mettre en priorité absolue un
processus devant les autres (comme chrt -f nn). Y a-t-il un moyen (en
particulier sous linux ou solaris) de rendre le gentil processus réellement
sous-prioritaire ?
J'entend par là : si rien n'est actif dans la file d'attente, alors on donne
la main à ce processus, mais si un ou plusieurs des autres processus normaux
se réveille alors le gentil processus n'a plus la main jusqu'à ce que les
autres se rendorment. (sous linux, chrt -f -1 n'est pas possible sans
toucher au noyo, ce que je n'ai pas encore essayé).
Sur une machine chargée, je donne une plus grande priorité à mplayer pour éviter les à-coups.
Mais je ne suis pas sur que ça soit vraiment efficace...
Sur le démon son de KDE artsd ça améliore un peu.
Pour artsd, sur ma machine (linux-x86) bonatoufer, le nice ne suffit pas. Alors je fais un truc pas très catholique au lancement du système :
nohup sh -c "while true; do chrt -f 99 su nobody -c "/usr/bin/artsd -a alsa -d -u -n -p 1025"; killall xmms mplayer; sleep 5; done" >& /tmp/aRts.log &
et je positionne ARTS_SERVER=localhost:1025 dans le profile global.
Cependant, il me semble que chrt est spécifique linux.
Le "while true" sert à relancer artsd des fois qu'il s'écroule. Ça arrive et je ne sais pas pourquoi.
Il faut faire gaffe avec chrt, si jamais il prenait au processus (artsd) l'envie de prendre tout le cpu, la boite serait bonne pour le reset.
A ce sujet, j'ai une question, en rapport avec le contraire du sujet de ce thread. J'aimerais avoir des processus (très gentils) de calcul en tâche de fond, qui eux auraient bien envie de prendre en permanence 100% du cpu (je sais que ce n'est pas très écologique...) mais qui ne doivent absolument pas gêner les autres.
La solution immédiate est "nice -n +19 commande...". Mais elle n'est que moyennement satisfaisante. On peut avec chrt mettre en priorité absolue un processus devant les autres (comme chrt -f nn). Y a-t-il un moyen (en particulier sous linux ou solaris) de rendre le gentil processus réellement sous-prioritaire ? J'entend par là : si rien n'est actif dans la file d'attente, alors on donne la main à ce processus, mais si un ou plusieurs des autres processus normaux se réveille alors le gentil processus n'a plus la main jusqu'à ce que les autres se rendorment. (sous linux, chrt -f -1 n'est pas possible sans toucher au noyo, ce que je n'ai pas encore essayé).
david
R12y
On Tue, 06 Sep 2005 21:38:43 +0000, david wrote:
nohup sh -c "while true; do chrt -f 99 su nobody -c "/usr/bin/artsd -a alsa -d -u -n -p 1025"; killall xmms mplayer; sleep 5; done" >& /tmp/aRts.log &
rien que ça? :-)
-- SPIP, phpNuke, Plone, opengroupware... c'est bien CPS c'est mieux: http://www.cps-project.org/ Hébergement de sites CPS: http://www.objectis.org/
On Tue, 06 Sep 2005 21:38:43 +0000, david wrote:
nohup sh -c "while true; do chrt -f 99 su nobody -c "/usr/bin/artsd -a alsa
-d -u -n -p 1025"; killall xmms mplayer; sleep 5; done" >& /tmp/aRts.log &
rien que ça? :-)
--
SPIP, phpNuke, Plone, opengroupware... c'est bien
CPS c'est mieux: http://www.cps-project.org/
Hébergement de sites CPS: http://www.objectis.org/
nohup sh -c "while true; do chrt -f 99 su nobody -c "/usr/bin/artsd -a alsa -d -u -n -p 1025"; killall xmms mplayer; sleep 5; done" >& /tmp/aRts.log &
rien que ça? :-)
-- SPIP, phpNuke, Plone, opengroupware... c'est bien CPS c'est mieux: http://www.cps-project.org/ Hébergement de sites CPS: http://www.objectis.org/
Vincent Bernat
OoO La nuit ayant déjà recouvert d'encre ce jour du mardi 06 septembre 2005, vers 23:38, david disait:
J'entend par là : si rien n'est actif dans la file d'attente, alors on donne la main à ce processus, mais si un ou plusieurs des autres processus normaux se réveille alors le gentil processus n'a plus la main jusqu'à ce que les autres se rendorment.
À ce que je sache, c'est exactement ce qu'il se passe. Si un processus a une gentillesse plus élevée qu'un autre, ce dernier prend la main aussi longtemps qu'il le veut sur le premier. Encore faut-il qu'il réussisse à la garder... -- Keep it right when you make it faster. - The Elements of Programming Style (Kernighan & Plauger)
OoO La nuit ayant déjà recouvert d'encre ce jour du mardi 06 septembre
2005, vers 23:38, david <deyv@free.fr> disait:
J'entend par là : si rien n'est actif dans la file d'attente, alors on donne
la main à ce processus, mais si un ou plusieurs des autres processus normaux
se réveille alors le gentil processus n'a plus la main jusqu'à ce que les
autres se rendorment.
À ce que je sache, c'est exactement ce qu'il se passe. Si un processus
a une gentillesse plus élevée qu'un autre, ce dernier prend la main
aussi longtemps qu'il le veut sur le premier. Encore faut-il qu'il
réussisse à la garder...
--
Keep it right when you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)
OoO La nuit ayant déjà recouvert d'encre ce jour du mardi 06 septembre 2005, vers 23:38, david disait:
J'entend par là : si rien n'est actif dans la file d'attente, alors on donne la main à ce processus, mais si un ou plusieurs des autres processus normaux se réveille alors le gentil processus n'a plus la main jusqu'à ce que les autres se rendorment.
À ce que je sache, c'est exactement ce qu'il se passe. Si un processus a une gentillesse plus élevée qu'un autre, ce dernier prend la main aussi longtemps qu'il le veut sur le premier. Encore faut-il qu'il réussisse à la garder... -- Keep it right when you make it faster. - The Elements of Programming Style (Kernighan & Plauger)
Arnaud Giersch
Mardi le 06 septembre 2005, vers 23:38:43 (CEST), david a écrit:
J'aimerais avoir des processus (très gentils) de calcul en tâche de fond, qui eux auraient bien envie de prendre en permanence 100% du cpu (je sais que ce n'est pas très écologique...) mais qui ne doivent absolument pas gêner les autres.
Bonjour,
Du temps où je jouais avec , j'utilisais loadwatch pour faire ce genre de chose (http://freshmeat.net/projects/loadwatch/). En gros, il stoppe le processus lorsque la charge du système dépasse un certain seuil, et le réveille quand elle retombe sous un autre seuil.
Arnaud
Mardi le 06 septembre 2005, vers 23:38:43 (CEST), david a écrit:
J'aimerais avoir des processus (très gentils) de calcul en tâche de
fond, qui eux auraient bien envie de prendre en permanence 100% du
cpu (je sais que ce n'est pas très écologique...) mais qui ne
doivent absolument pas gêner les autres.
Bonjour,
Du temps où je jouais avec seti@home, j'utilisais loadwatch pour faire
ce genre de chose (http://freshmeat.net/projects/loadwatch/). En
gros, il stoppe le processus lorsque la charge du système dépasse un
certain seuil, et le réveille quand elle retombe sous un autre seuil.
Mardi le 06 septembre 2005, vers 23:38:43 (CEST), david a écrit:
J'aimerais avoir des processus (très gentils) de calcul en tâche de fond, qui eux auraient bien envie de prendre en permanence 100% du cpu (je sais que ce n'est pas très écologique...) mais qui ne doivent absolument pas gêner les autres.
Bonjour,
Du temps où je jouais avec , j'utilisais loadwatch pour faire ce genre de chose (http://freshmeat.net/projects/loadwatch/). En gros, il stoppe le processus lorsque la charge du système dépasse un certain seuil, et le réveille quand elle retombe sous un autre seuil.
Arnaud
Laurent Wacrenier
Arnaud Giersch écrit:
Du temps où je jouais avec , j'utilisais loadwatch pour faire ce genre de chose (http://freshmeat.net/projects/loadwatch/). En gros, il stoppe le processus lorsque la charge du système dépasse un certain seuil, et le réveille quand elle retombe sous un autre seuil.
Sur FreeBSD, il y a des commande "idprio" ou "rtprio" qui permettent de n'attribuer des ressources CPU que lorsque personne d'autre ne les utilise ou au contraire en priorité.
Arnaud Giersch <arnaud.giersch@free.fr> écrit:
Du temps où je jouais avec seti@home, j'utilisais loadwatch pour faire
ce genre de chose (http://freshmeat.net/projects/loadwatch/). En
gros, il stoppe le processus lorsque la charge du système dépasse un
certain seuil, et le réveille quand elle retombe sous un autre seuil.
Sur FreeBSD, il y a des commande "idprio" ou "rtprio" qui permettent
de n'attribuer des ressources CPU que lorsque personne d'autre ne les
utilise ou au contraire en priorité.
Du temps où je jouais avec , j'utilisais loadwatch pour faire ce genre de chose (http://freshmeat.net/projects/loadwatch/). En gros, il stoppe le processus lorsque la charge du système dépasse un certain seuil, et le réveille quand elle retombe sous un autre seuil.
Sur FreeBSD, il y a des commande "idprio" ou "rtprio" qui permettent de n'attribuer des ressources CPU que lorsque personne d'autre ne les utilise ou au contraire en priorité.
david
Vincent Bernat wrote:
OoO La nuit ayant déjà recouvert d'encre ce jour du mardi 06 septembre 2005, vers 23:38, david disait:
J'entend par là : si rien n'est actif dans la file d'attente, alors on donne la main à ce processus, mais si un ou plusieurs des autres processus normaux se réveille alors le gentil processus n'a plus la main jusqu'à ce que les autres se rendorment.
À ce que je sache, c'est exactement ce qu'il se passe. Si un processus a une gentillesse plus élevée qu'un autre, ce dernier prend la main aussi longtemps qu'il le veut sur le premier. Encore faut-il qu'il réussisse à la garder...
Sous linux avec un noyau 2.6, ce n'est pas le cas, du moins avec les priorités standard de nice. La priorité est relative, pas absolue. sinon avec les commandes suivante, j'aurais bloqué ma machine :
:~>nice -n +19 sh -c "while true; do true; done" & [1] 3573 :~>nice -n -19 sh -c "while true; do true; done" & [2] 3577
top renvoie (il y a d'autres processus) :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3577 root 6 -19 4812 1244 944 R 94.9 0.1 0:35.96 sh 3573 root 39 19 4808 1240 944 R 0.6 0.1 0:03.55 sh
david
Vincent Bernat <bernat@luffy.cx> wrote:
OoO La nuit ayant déjà recouvert d'encre ce jour du mardi 06 septembre
2005, vers 23:38, david <deyv@free.fr> disait:
J'entend par là : si rien n'est actif dans la file d'attente, alors on donne
la main à ce processus, mais si un ou plusieurs des autres processus normaux
se réveille alors le gentil processus n'a plus la main jusqu'à ce que les
autres se rendorment.
À ce que je sache, c'est exactement ce qu'il se passe. Si un processus
a une gentillesse plus élevée qu'un autre, ce dernier prend la main
aussi longtemps qu'il le veut sur le premier. Encore faut-il qu'il
réussisse à la garder...
Sous linux avec un noyau 2.6, ce n'est pas le cas, du moins avec les
priorités standard de nice. La priorité est relative, pas absolue. sinon
avec les commandes suivante, j'aurais bloqué ma machine :
root@tunnel:~>nice -n +19 sh -c "while true; do true; done" &
[1] 3573
root@tunnel:~>nice -n -19 sh -c "while true; do true; done" &
[2] 3577
top renvoie (il y a d'autres processus) :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3577 root 6 -19 4812 1244 944 R 94.9 0.1 0:35.96 sh
3573 root 39 19 4808 1240 944 R 0.6 0.1 0:03.55 sh
OoO La nuit ayant déjà recouvert d'encre ce jour du mardi 06 septembre 2005, vers 23:38, david disait:
J'entend par là : si rien n'est actif dans la file d'attente, alors on donne la main à ce processus, mais si un ou plusieurs des autres processus normaux se réveille alors le gentil processus n'a plus la main jusqu'à ce que les autres se rendorment.
À ce que je sache, c'est exactement ce qu'il se passe. Si un processus a une gentillesse plus élevée qu'un autre, ce dernier prend la main aussi longtemps qu'il le veut sur le premier. Encore faut-il qu'il réussisse à la garder...
Sous linux avec un noyau 2.6, ce n'est pas le cas, du moins avec les priorités standard de nice. La priorité est relative, pas absolue. sinon avec les commandes suivante, j'aurais bloqué ma machine :
:~>nice -n +19 sh -c "while true; do true; done" & [1] 3573 :~>nice -n -19 sh -c "while true; do true; done" & [2] 3577
top renvoie (il y a d'autres processus) :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3577 root 6 -19 4812 1244 944 R 94.9 0.1 0:35.96 sh 3573 root 39 19 4808 1240 944 R 0.6 0.1 0:03.55 sh
david
david
Laurent Wacrenier <lwa@ teaser . fr> wrote:
Arnaud Giersch écrit:
Du temps où je jouais avec , j'utilisais loadwatch pour faire ce genre de chose (http://freshmeat.net/projects/loadwatch/). En gros, il stoppe le processus lorsque la charge du système dépasse un certain seuil, et le réveille quand elle retombe sous un autre seuil.
Sur FreeBSD, il y a des commande "idprio" ou "rtprio" qui permettent de n'attribuer des ressources CPU que lorsque personne d'autre ne les utilise ou au contraire en priorité.
Il semble que rtprio de freebsd est équivalent à chrt sous linux. Par contre idprio est effectivement ce que je cherchais et ce qu'il manque à linux. Merci pour l'info, et aussi pour loadwatch.
Un jour, je trouverai le temps de découvrir tous les bienfaits de freebsd :-] Un autre jour, je trouverai le temps de regarder deplus près le code du scheduler de linux [-;
david
Laurent Wacrenier <lwa@ teaser . fr> wrote:
Arnaud Giersch <arnaud.giersch@free.fr> écrit:
Du temps où je jouais avec seti@home, j'utilisais loadwatch pour faire
ce genre de chose (http://freshmeat.net/projects/loadwatch/). En
gros, il stoppe le processus lorsque la charge du système dépasse un
certain seuil, et le réveille quand elle retombe sous un autre seuil.
Sur FreeBSD, il y a des commande "idprio" ou "rtprio" qui permettent
de n'attribuer des ressources CPU que lorsque personne d'autre ne les
utilise ou au contraire en priorité.
Il semble que rtprio de freebsd est équivalent à chrt sous linux. Par contre
idprio est effectivement ce que je cherchais et ce qu'il manque à linux.
Merci pour l'info, et aussi pour loadwatch.
Un jour, je trouverai le temps de découvrir tous les bienfaits de freebsd :-]
Un autre jour, je trouverai le temps de regarder deplus près le code du
scheduler de linux [-;
Du temps où je jouais avec , j'utilisais loadwatch pour faire ce genre de chose (http://freshmeat.net/projects/loadwatch/). En gros, il stoppe le processus lorsque la charge du système dépasse un certain seuil, et le réveille quand elle retombe sous un autre seuil.
Sur FreeBSD, il y a des commande "idprio" ou "rtprio" qui permettent de n'attribuer des ressources CPU que lorsque personne d'autre ne les utilise ou au contraire en priorité.
Il semble que rtprio de freebsd est équivalent à chrt sous linux. Par contre idprio est effectivement ce que je cherchais et ce qu'il manque à linux. Merci pour l'info, et aussi pour loadwatch.
Un jour, je trouverai le temps de découvrir tous les bienfaits de freebsd :-] Un autre jour, je trouverai le temps de regarder deplus près le code du scheduler de linux [-;
david
andrea ferraris
david ecrit:
Un jour, je trouverai le temps de découvrir tous les bienfaits de freebsd :-] Un autre jour, je trouverai le temps de regarder deplus près le code du scheduler de linux [-;
Jammais essaie', mais dans la configuration du 2.6 on peut choisir parmis differents scheduler et il me semble qu'il y a aussi des options pour le real time.
Andrea
david ecrit:
Un jour, je trouverai le temps de découvrir tous les bienfaits de freebsd :-]
Un autre jour, je trouverai le temps de regarder deplus près le code du
scheduler de linux [-;
Jammais essaie', mais dans la configuration du 2.6 on peut choisir
parmis differents scheduler et il me semble qu'il y a aussi des options
pour le real time.
Un jour, je trouverai le temps de découvrir tous les bienfaits de freebsd :-] Un autre jour, je trouverai le temps de regarder deplus près le code du scheduler de linux [-;
Jammais essaie', mais dans la configuration du 2.6 on peut choisir parmis differents scheduler et il me semble qu'il y a aussi des options pour le real time.
