Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Réduire l'utilisation CPU en compilation

Réduire l'utilisation CPU en compilation

10 réponses
Avatar
Doff
Salut,

savez vous comment dire =E0 mon linux de ne pas utiliser plus de 50% de=20
CPU quand il compile ?

C'est un vieux processeur, et j'aimerai bien faire autre chose quand il=20
compile, meme si la compilation est plus longue...

Merci
Signaler un problème avec ce contenu

10 réponses

Supprimer
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
Avatar
Arnaud Gomes-do-Vale
Doff writes:

savez vous comment dire à mon linux de ne pas utiliser plus de 50% de
CPU quand il compile ?


Non.

C'est un vieux processeur, et j'aimerai bien faire autre chose quand il
compile, meme si la compilation est plus longue...


man nice

--
Arnaud

Avatar
Bonnepluie
Il doit y avoir moyen de régler ça dans les paramètres des utilisateurs.
Donc si je ne me trompe pas, tu créés un utilisateur compil, tu lances ta
compile avec cet utilisateur dans une session quelconque, et pendant ce
temps tu utilises ton linux normalement, ou presque...

Le problème, c'est que je ne me souviens où j'ai vu cette histoire de
limitation pour un utilisateur...

Désolé

Bonnepluie
Avatar
Thierry Boudet
In article , Doff wrote:

savez vous comment dire à mon linux de ne pas utiliser plus de 50% de
CPU quand il compile ?
C'est un vieux processeur, et j'aimerai bien faire autre chose quand il
compile, meme si la compilation est plus longue...

$ nice ma_compile


--
[Linux] c'est une philosophie un art de vivre, un état intérieur,
une sorte de fluide qui nous entoure et nous pénètre.
Fais tourner stp !

-+- Guillaume in Guide du linuxien pervers - "Tous drogués j'vous dis !"

Avatar
Remi Moyen
On Tue, 29 Jul 2003, Bonnepluie wrote:

Il doit y avoir moyen de régler ça dans les paramètres des utilisateurs.
Donc si je ne me trompe pas, tu créés un utilisateur compil, tu lances ta
compile avec cet utilisateur dans une session quelconque, et pendant ce
temps tu utilises ton linux normalement, ou presque...

Le problème, c'est que je ne me souviens où j'ai vu cette histoire de
limitation pour un utilisateur...


Tu penses à ulimit, je suppose (décrit dans le man de bash, par exemple).
Mais je viens de regarder, et chez moi, ulimit ne permet de limiter que la
durée d'utilisation du cpu, pas le pourcentage. Peut-être que d'autres
versions permettent ce genre de limitations, remarque.
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."

Avatar
Bonnepluie
Ben, en fait, c'est plutôt la priorité des threads qu'on choisi. Avec un
utilisateur lambda, impossible d'avoir un thread en priorité temps réel. Il
faut être root, ou bien bidouiller un truc à partir des modules du
noyaux... ?

Bonnepluie
Avatar
Marc Mezzarobba

C'est un vieux processeur, et j'aimerai bien faire autre chose quand
il compile, meme si la compilation est plus longue...


man nice


À propos, est-ce qu'il y a un moyen pas trop crade soit de changer le
nice par défaut pour tous les processus, soit d'autoriser les
utilisateurs normaux à descendre à -10 ? Bref, de faire en sorte qu'un
utilisateur puisse (re)nicer des choses en-dessous du défaut ? Ou,
mieux encore, de permettre à chacun de faire cela pour un et un seul
processus à la fois ?

L'idée que j'ai derrière la tête, c'est que même si (paraît-il)
l'ordonnanceur de Linux privilégie les tâches « interactives », ce
n'est pas franchement utile/efficace pour les trucs qui ont une
interface graphique. Ce serait sympa d'avoir un wm qui, quand on donne
le focus à une fenêtre, augmente le priorité de la tâche
correspondante. (J'ai constaté en essayant à la main qu'avec certains
logiciels, comme gqview, on sent la différence.)

--
Marc Mezzarobba --- http://marc.mezzarobba.net
% Mon adresse email principale est désormais de la forme
% pré


Avatar
Thierry Boudet
In article <bg6i1g$q7r$, Marc Mezzarobba wrote:

C'est un vieux processeur, et j'aimerai bien faire autre chose quand
il compile, meme si la compilation est plus longue...


man nice


À propos, est-ce qu'il y a un moyen pas trop crade soit de changer le
nice par défaut pour tous les processus, soit d'autoriser les


je pense que la valeur par défaut a été choisie avec soin
par les concepteurs du système. j'avais à une époque réussi
à renicer à -5 les shells sur une ttyS0 par je ne sais plus
quelle magouille. mais bon...

utilisateurs normaux à descendre à -10 ? Bref, de faire en sorte qu'un
utilisateur puisse (re)nicer des choses en-dessous du défaut ? Ou,


le defaut est -10
$ nice -19 ./plop.rb
va lui donner la priorité minimum.

mieux encore, de permettre à chacun de faire cela pour un et un seul
processus à la fois ?

man nice. man renice.


L'idée que j'ai derrière la tête, c'est que même si (paraît-il)
l'ordonnanceur de Linux privilégie les tâches « interactives », ce
n'est pas franchement utile/efficace pour les trucs qui ont une


je ne comprends pas trop, là...

interface graphique. Ce serait sympa d'avoir un wm qui, quand on donne
le focus à une fenêtre, augmente le priorité de la tâche
correspondante. (J'ai constaté en essayant à la main qu'avec certains


seul root a la possibilité d'augmenter le nicelevel d'un
process. sinon, ça deviendrait vite le b*rd*l.

logiciels, comme gqview, on sent la différence.)




--
main(k){float i,j,r,x,y=-16;while(puts(""),y++<15)
for(x=0;x++<84;putchar(" .:-;!/>)|&IH%*#"[k&15]))
for(i=k=r=0;j=r*r-i*i-2+x/25,i=2*r*i+y/10,j*j+i*i<11&&k++<111;r=j);}



Avatar
J. Mayer
On Tue, 29 Jul 2003 19:49:44 +0000, Thierry Boudet wrote:

In article <bg6i1g$q7r$, Marc Mezzarobba wrote:

C'est un vieux processeur, et j'aimerai bien faire autre chose quand
il compile, meme si la compilation est plus longue...


man nice


À propos, est-ce qu'il y a un moyen pas trop crade soit de changer le
nice par défaut pour tous les processus, soit d'autoriser les


je pense que la valeur par défaut a été choisie avec soin
par les concepteurs du système. j'avais à une époque réussi
à renicer à -5 les shells sur une ttyS0 par je ne sais plus
quelle magouille. mais bon...



Ils sont en train de faire des tests intensifs pour avoir
un scheduler tres efficace dans le 2.6.0...
Celui du 2.4 est un peu simpliste et a quelques problemes,
surtout les derniers, lorsque les I/O sont tres chargees
(gros access disques, etc...).

utilisateurs normaux à descendre à -10 ? Bref, de faire en sorte qu'un
utilisateur puisse (re)nicer des choses en-dessous du défaut ? Ou,


le defaut est -10
Non. Cf la norme POSIX:

le defaut est 0, et le renice va de -20 a +20.
Les valeurs negatives sont reservees au root.
20 est la priorite la PLUS FAIBLE.

L'idée que j'ai derrière la tête, c'est que même si (paraît-il)
l'ordonnanceur de Linux privilégie les tâches « interactives », ce
n'est pas franchement utile/efficace pour les trucs qui ont une
interface graphique. Ce serait sympa d'avoir un wm qui, quand on donne
le focus à une fenêtre, augmente le priorité de la tâche
correspondante. (J'ai constaté en essayant à la main qu'avec certains


seul root a la possibilité d'augmenter le nicelevel d'un
process. sinon, ça deviendrait vite le b*rd*l.
C'est une question de securite:

le root a ainsi toujours un moyen pour reprendre la main
sur une application qui consemerait tout le CPU, par exemple
pour la tuer.
Et ce n'est pas specifique Linux, c'est dans la spec POSIX.

Pour fixer la priorite par defaut d'un utilisateur toto,
dans /etc/passwd (n est la priorite voulue).
toto:x:1000:1000:pri=n:/home/toto:/bin/bash




Avatar
Vincent Bernat
OoO En ce début de soirée du mardi 29 juillet 2003, vers 21:29, Marc
Mezzarobba disait:

À propos, est-ce qu'il y a un moyen pas trop crade soit de changer le
nice par défaut pour tous les processus, soit d'autoriser les
utilisateurs normaux à descendre à -10 ? Bref, de faire en sorte qu'un
utilisateur puisse (re)nicer des choses en-dessous du défaut ?


L'interdiction n'est pas en-dessous de la valeur par défaut, mais
en-dessous de la valeur actuelle. Si la valeur actuelle est -10, tu
peux mettre -5, mais pas -15.

Ou,
mieux encore, de permettre à chacun de faire cela pour un et un seul
processus à la fois ?


Un petit programme en C setuid root devrait faire l'affaire, mais il
suffit alors d'itérer pour atteindre -20. À utiliser avec précautions.
--
I WILL NOT BRING SHEEP TO CLASS
I WILL NOT BRING SHEEP TO CLASS
I WILL NOT BRING SHEEP TO CLASS
-+- Bart Simpson on chalkboard in episode 9F06

Avatar
J. Mayer
On Wed, 30 Jul 2003 00:09:34 +0000, Thierry Boudet wrote:

In article , J. Mayer wrote:

utilisateurs normaux à descendre à -10 ? Bref, de faire en sorte qu'un
utilisateur puisse (re)nicer des choses en-dessous du défaut ? Ou,


le defaut est -10
Non. Cf la norme POSIX:

le defaut est 0, et le renice va de -20 a +20.
Les valeurs negatives sont reservees au root.
20 est la priorite la PLUS FAIBLE.

Je pensais à la valeur par defaut pour la commande nice...

Ah, pardon, desole...



Pour fixer la priorite par defaut d'un utilisateur toto,
dans /etc/passwd (n est la priorite voulue).
toto:x:1000:1000:pri=n:/home/toto:/bin/bash

C'est géré par quoi cette fonctionnalité ?

C'est la première fois de ma vie que je vois un
paramètre système dans le Gecos :)


Tire de `info login`:
Your user and group ID will be set according to their val-
ues in the /etc/passwd file. The value for $HOME, $SHELL,
$PATH, $LOGNAME, and $MAIL are set according to the appro-
priate fields in the password entry. Ulimit, umask and
nice values may also be set according to entries in the
GECOS field.

et `man 5 passwd`:
The comment field is used by various system utilities,
such as finger(1). Three additional values may be present
in the comment field. They are

pri= - set initial value of nice

umask= - set initial value of umask

ulimit= - set initial value of ulimit

These fields are separated from each other and from any
other comment field by a comma.

Cordialement.